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Scope 



The present document specifies the architecture and functions of an IPTV system that makes use of the NGN IMS 
architecture and its features, implementing the requirements defined in TS 181 014 [14] and TS 181 016 [15]. 

The present document has taken IPTV solutions defined by other organizations (such as DVB, ATIS IIF, etc.) into 
account. It is based on an IMS based architecture and where appropriate the aforementioned solutions are referenced. 

By relying on common components the resulting architecture can coexist with other TISPAN NGN services. 

NOTE: As the use of IPTV services may release personal data the provider of IPTV services is expected to 

comply with relevant privacy protection principles as specified for Identity Management in the NGN in 
TS 187 016 [19]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Functional Architecture". 

[2] ETSI TS 182 006: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Stage 2 description 
[3GPP TS 23.506 Release 8, modified]". 

[3] ETSI ES 282 004: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment 

Sub-System (NASS)". 

[4] ETSI TS 133 220: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Generic Authentication Architecture (GAA); Generic 
bootstrapping architecture (3GPP TS 33.220)". 

[5] ETSI TS 187 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Security; Security Architecture". 

[6] ETSI TS 102 034: "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB 

Services over IP Based Networks". 

[7] ITU-T Recommendation P. 10/G. 100 "Vocabulary for performance and quality of service " 

- New Appendix I - Definition of Quality of Experience (QoE). 

[8] ETSI ES 282 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS): 
Functional Architecture". 
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[9] ETSI TS 183 004: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services: Communication Diversion 
(CDIV); Protocol specification". 

[10] ETSI TS 182 008: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Presence Service; Architecture and functional description 
[Endorsement of 3GPP TS 23.141 and OMA-AD-Presence-SIMPLE-Vl-0]". 

[11] ETSI ES 282 007: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture". 

[12] Void. 

[13] ETSI ES 283 030: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Presence Service Capability; Protocol Specification 
[3GPP TS 24.141 V7.0.0, modified and OMA-TS-Presence-SIMPLE-Vl-0, modified]". 

[14] ETSI TS 181 014: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Requirements for network transport capabilities to support 
IPTV services". 

[15] ETSI TS 181 016: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Service Layer Requirements to integrate NGN services and 
IPTV". 

[16] ETSI TS 122 340: "Universal Mobile Telecommunications System (UMTS); IP Multimedia 

Subsystem (IMS) messaging; Stage 1 (3GPP TS 22.340 version 7.0.0 Release 7)". 

[17] ETSI TS 123 237: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS) Service Continuity; 
Stage 2 (3GPP TS 23.237 Release 9)". 

[18] ETSI TS 124 237: "Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia 

(IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuity; Stage 3 
(3GPP TS 24.237 Release 9)". 

[19] ETSI TS 187 016: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Security; Identity Protection (Protection Profile)". 

[20] Void. 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] DSL Forum Technical Report TR-126: "Triple-play Services Quality of Experience (QoE) 

Requirements". 

[i.2] Void. 

[i.3] ETSI ES 282 010: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Charging management [Endorsement of 3GPP TS 32.240 
Release 7, 3GPP TS 32.260 Release 7, 3GPP TS 32.297 Release 7, 3GPP TS 32.298 Release 7 and 
3GPP TS 32.299 Release 7, modified]". 

[i.4] ETSI TR 182 005: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Organization of user data". 

[i.5] ETSI ES 204 915(all parts): "Open Service Access (OSA); Application Programming Interface 

(API); (Parlay 6.0)". 

[i.6] ETSI ES 202 504 (all parts): " Open Service Access (OSA); Parlay X Web Services; 

(Parlay X 3)". 
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[i.7] ETSI TS 129 198 (all parts): "Universal Mobile Telecommunications System (UMTS); LTE; Open 

Service Access (OSA) Application Programming Interface (API); (3GPP TS 29.198 Release 7)". 

[i.8] ETSI TS 123 002: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Network architecture (3GPP TS 23.002 Release 8)". 

[i.9] ETSI TS 123 218: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; IP Multimedia (IM) session handling; IM call model; 
Stage 2 (3GPP TS 23.218 Release 8)". 

[i.lO] 3GPP TR 23.810: " Technical Specification Group Services and System Aspects; Study on 

Architecture Impacts of Service Brokering; (Release 8)". 

[i.l 1] Toshiro Nunome; Shuji Tasaka, "An Application-Level QoS Comparison of Inter-Destination 

Synchronization Schemes for Continuous Media Multicasting", lElCE transactions on 
communications, ISSN 0916-8516, Vol. 87 (2004), No. 10, pp. 3057-3067 (11). 

[i.l2] SCTE-130 part 1: "Advertising Systems Overview". 

[i.l3] SCTE-130 part 2: "Core Data Elements". 

[i. 14] SCTE-130 part 3: "Ad Management Service interface". 

[i.l5] OMA MobAd 1.0 RD: "Mobile Advertising Requirements". 

[i.l6] OMA MobAd 1.0 AD: "Mobile Advertising Architecture". 

[i.l7] Void. 

[i. 1 8] ITU-T Recommendation J. 1 8 1 : "Digital program insertion cueing message for cable television 

systems". 

[i.l9] ETSI TS 129 199 (all parts): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); LTE; Open Service Access (OSA); Parlay X web 
services; (3GPP TS 29.199 version 8.1.0 Release 8)". 

[i.20] ETSI TS 126 234: "Universal Mobile Telecommunications System (UMTS); LTE; Transparent 

end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs (3GPP TS 26.234 
Release 8)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

content control: procedure for controlling content delivery 

NOTE: E.g. starting content delivery, playback of content (such as pause, fast and slow playback, reverse 
playback, rewinding, jumping forwards or backwards), stopping content delivery), and content 
management (e.g. digital rights management, program scheduling management, delivery management. 

content delivery: procedure for delivering multimedia contents 

content Provider: entity that owns or is licensed to sell content or content assets 

content protection: protection of content or content assets during its entire lifetime 

NOTE: The content provider defines the lifetime that the protection is required for 
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IPTV Service Access History (SAH): collection of a user's service states and service actions as well as other 
information 

NOTE: Examples include accessed service types, watched content and time of watching 
IPTV content identifier: superclass of the identifiers that identify content in specific IPTV services 
IPTV Service Action Data (SAD): persistent record of actions that a user has made; for use in access to IPTV services 

NOTE: Examples include BC bookmarks, available CoD, PVR items and UGC items. 

IPTV service state: snapshot of the information related to an ongoing IPTV service 

NOTE: Examples include the current BC program ID, the ID of current CoD content, the state of PVR 

recordings, the media state of services and invoked trick play events, commercial breaks in services and 
combinations of these. 

IPTV Service State Data (SSD): information about IPTV service state and service actions 

NOTE 1 : This information may be held in network elements that constitute the IPTV solution or external 
applications. 

NOTE 2: The relationship between SSD, SAD and SAH is as follows: 

■ SSD is information about the present meant for immediate use, e.g. inserting a targeted 
advertisement or performing an action on an incoming phone call. 

■ SAD is information meant for future service access, e.g. a user setting and later retrieving a BC 
bookmark to see (again) the bookmarked content. 

■ SAH is information meant for user preference extraction and sharing services, e.g. for service 
personalization, targeting, and sharing consumption history among authorized users. 

IPTV Service protection: managing authorized access to the IPTV-service; the protection of IPTV-content (e.g. files 
or streams) and IPTV-service information during delivery which may include content already protected and meta data 
that the service provider adds to the content 

NOTE: The IPTV service may be composed of the content to be transfered and other data and service 

components. Service protection addresses protecting this composition while in transit and regulates 
authorized access to the service. Additionally it addresses ensuring the service availability, as defined in 
the service level agreements. 

IPTV service type identifier: identifies type of IPTV services 

media stream identifier: identifier carried in a unicast or multicast media stream that identifies that specific media 
stream 

offset: value indicating the elapsed time between the beginning of content and the current reading position of the 
reading cursor in that same streamed content 

park TV: feature that would enable a user (on a UE) make an impulsive request to record ongoing BC 
service/programme from a particular point in time 

NOTE: This recording point is also referred to as a bookmark. 

park and pickup TV: feature that would enable a user (on a UE) to Park TV and subsequently Pickup TV 

pickup TV: feature that would enable a user (on a UE) retrieve or request BC service/programme that was recorded and 
bookmarked via an impulsive record request 

NOTE: The IPTV content can be retrieved from the bookmarked location or recording point on same or different 
UE at a later point in time. 

programme: entry in the Electronic Programme Guide 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ADM Ad Management Service 

ADS Ad Decision Service 

BC Broadcast 

CIS Content Information Service 

CM Content marker 

CoD Content on Demand 

C-PVR Client Personal Video Recorder 

CR Content Recommendation 

CRS Content Recommendation Service 

CSF Content Security Functions 

ECF Elementary Control Function 

EF Elementary Functions 

EFF Elementary Forwarding Function 

EPG Electronic Programme Guide 

GAA Generic Authentication Architecture 

GBA Generic Bootstrapping Architecture 

HD High Definition 

ICM Incoming Call Management 

IGMP Internet Group Management Protocol 

IMPU IMS Public User Identity 

IMS IP Multimedia Subsystem 

IPTV IP Television 

MCF Media Control Function 

MCN Media Channel Negotiation 

MDF Media Delivery Function 

MF Media Function 

MSAS Media Synchronization Application Server 

NASS Network Attachment Subsystem 

NGN Next Generation Network 

N-PVR Network-Personal Video Recorder 

PC Parental controlled 

POIS Placement Opportunity Information Service 

PSC Personalized Stream Composition 

PVR Personal Video Recorder 

QoE Quality of Experience 

QoS Quality Of Service 

RACS Resource and Admission Control Subsystem 

SAD Service Action Data 

SAH Service Access History 

SC Synchronization Client 

SCF Service Control Function 

SCIM Service Capability Interaction Manager 

SCS Service Capability Server 

SD Standard Definition 

SDF Service Discovery Function 

SIP Session Initiation Protocol 

SIS 'Subscriber Information Service 

SKMF Service Key Management elementary Functions 

SLF Subscription Locator Function 

SMF Service Membership elementary Functions 

SPF Service Protection elementary Functions 

SSC Shared Service Control 

SSD Service State Data 

SSF Service Selection Function 

TAI Targeted Advertisement Insertion 

TPF Transport Processing Functions 

UE User Equipment 
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UGC User Generated Content 

UPSF User Profile Server Function 

URI Uniform Resource Identifier 

XDMS XML Document Management Server 



High-level overview 
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Figure 1 : High level functional architecture for IMS-based IPTV 

NOTE 1 : The specification of management functions and content provider functions is considered out of scope of 
the present document. 

User equipment 

UE: The IPTV enabled UE terminates the IPTV control and media signals, and displays the corresponding information 
to the user. The UE interaction with the user allows selection of programme, content, and service descriptions, such as 
content guides for broadcast and VoD services. 

Application functions and IPTV service functions 

Enables operation of or provides IPTV services. This includes IPTV Service Supporting Functions. 

IPTV Service Supporting Function: The IPTV Service Supporting Function defined here are those common functions 
which could support or be used by other IPTV service or applications. 

NOTE 2: Examples of IPTV service supporting functions may be Service Discovery and Selection functions. 
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User Profiles 

User Profiles includes user data that are involved in providing IPTV services. 

Core IMS 

It provides functionality for authentication, authorization, and signalling for the setup of the service provisioning and 
content delivery. It routes signalling messages to the appropriate application server or triggers the applications based on 
settings maintained in the UPSF. For resource reservation and admission control this function interacts with the RACS. 

Transport Functions 

Transport Control: contains functions from RACS and NASS. It provides policy control, resource reservation and 
admission control as well as IP address provisioning, network level user authentication and access network 
configuration as defined in TISPAN. 

Transport Processing Functions: represents network access links and IP core. The IP core is in charge of data 
transmission with quality of service support. 

Media Delivery, Distribution and Storage 

The Media Delivery, Distribution and storage function receives and stores live feeds and media streams coming into the 
IPTV System from Content Providers. It is mainly in charge of media processing, delivery, storing, trans-coding and 
relaying. This function performs all these tasks along with the control of - or feedback to the IPTV Service and Control. 
Content protection may also be performed here or already protected content could be delivered over these 
functionalities. 



5 Overview of functional entities 

5.1 Functional architecture for IPTV services 
5.1 .1 Functional architecture overview 

The overall functional architecture for IPTV service is shown in figure 2. 
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IPTV Servic^ 

Control 

Functions 




Figure 2: Functional architecture for IPTV services 

NOTE 1: Only Xc and Xd are explicitly shown as traversing the Transport Processing Functions. For the sake of 
simplicity other reference points are only shown as end to end. 

In figure 2, the IPTV Service Control Functions, the IPTV Media Functions, the Service Selection Function (SSF) and 
the Service Discovery Function (SDF) fit in the context of TISPAN NGN Functional Architecture Release 2 [1]. 

NOTE 2: To support the regionalized delivery of content and metadata in accordance with applicable regulations, at 
least one of the service layer entities involved in the IPTV service should query the UE location from the 
NASS and enforce the regionalization. 

As stated in [2], the IMS architecture shall be based on the principle that the service control for Home subscribed 
services for a roaming subscriber is in the Home network. This principle shall be applied also in case the IPTV solution 
supports roaming. 

5.1.2 IPTV services 
5.1.2.0 Compliance 

An IPTV solution is compliant to the present document if the following points are fulfilled. 

• All mandatory services and features are implemented as specified in the present document. 

• If an optional service or feature is implemented, then it is implemented as specified in the present document. 

• If an optional service or feature is implemented, and the present document specifies multiple options, then it is 
implemented according to at least one or those options. 
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The IMS based IPTV architecture in this release should be fully backward compatible with architecture and services 
specified in previous release. 

NOTE: Any backwards compatibility issues need to be explicitly mentioned. 



5.1.2.1 



General 



IPTV services execution involves three functions: a service control function (SCF), a media control function (MCF) and 
a media delivery function (MDF). 

An SCF may host the logic of one or more of the following services as defined in TS 181 016 [15]: 

The following table 1 provide list of services and feature supported by TISPAN IMS based IPTV architecture (selection 
based on [1] and procedures described in TISPAN): 

NOTE: In certain cases, TS 181 016 [15] provides insufficient guidance with respect to the mandatory/optional 
nature of services. If a service has been specified as "mandatory" within the Service Layer Requirements 
specification but the corresponding requirements have not been clearly mandated, the service has been 
specified as "Optional" or "Mandatory/Optional" (with appropriate qualifying Note) within table 1 . 

Table 1 : IPTV services and features supported by TISPAN IMS based IPTV subsystem 



NGN IPTV 
Service and Feature 


TISPAN R2 

Service Layer 

Requirements to 

Integrate 

NGN Services 

and IPTV 


TISPAN R2 

IPTV 

Architecture; 

IPTV functions 

supported by 

the IMS 

subsystem 


TISPAN R3 
Service Layer 
Requirements 

to Integrate 

NGN Services 

and IPTV 


TISPAN R3 

IPTV 

Architecture; 

IPTV functions 

supported by the 

IMS subsystem 


Specification 


TS181 016 [15] 
Release 2 


TS 182 027 
Release 2 


TS181 016 [15] 
Release 3 


TS 1 82 027 
Release 3 


Linear/ Broadcast TV 


M 


M 


M 


M 


Linear/ Broadcast TV with Tricl< Play 


M 





M 





Time Sliifted TV 














Content on Demand (CoD) 


M 


M 


M 


M 


Push CoD 


NA 


NA 








Network PVR 


M 


M/O 
(see note 2) 


M 


M/O 
(see note 2) 


Client PVR 


NA 


NA 





0(See 
NOTE 2) 


Audio 


M 





M 





Pay-Per-View 


NA 


NA 


M 





Interactive TV 


NA 


NA 


M 





Service discovery 


M 


M 


M 


M 


Service Information (EPG) 


M 


M 


M 


M 


Parental Control 


M 


M/O 
(see note 3) 


M 


M/O 
(see note 3) 


User Profiling and Personalization 














Communications and Messaging 


NA 


NA 








Notifications 


NA 


NA 








IPTV Presence 














Interaction between users 


NA 


N/A 








Interaction with NGN services 














Advertising 


M 


M 
(see note 4) 


M 


M 
(see note 4) 


Targeted Advertising 


NA 


NA 








User Generated Content 


NA 


NA 


M 





Internationalization 














Content recommendation 


NA 


NA 








Games 


NA 


NA 








Picture 


NA 


NA 








Bookmarks 


NA 


NA 








Personalized channel 


NA 


NA 








Personalized Service Composition 


NA 


NA 








Service Portability 


NA 


NA 
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NGN IPTV 
Service and Feature 


TISPAN R2 

Service Layer 

Requirements to 

Integrate 

NGN Services 

and IPTV 


TISPAN R2 

IPTV 

Architecture; 

IPTV functions 

supported by 

the IMS 

subsystem 


TISPAN R3 
Service Layer 
Requirements 

to Integrate 

NGN Services 

and IPTV 


TISPAN R3 

IPTV 

Architecture; 

IPTV functions 

supported by the 

IMS subsystem 


Service Continuation between IPTV 
UEs 


NA 


NA 








Service Continuation fixed-mobile 


NA 


NA 








Remote Control of IPTV services 


NA 


NA 








Emergency Information. 


NA 


NA 








Interaction with 3'° Party application 
(e.g. Parlay) 


NA 


NA 








Service synchronization 


NA 


NA 








Incoming call management 


NA 


NA 








N0TE1 
NOTE 2 
NOTES 
NOTE 4 


M - Mandatory, 0- Optional, NA - not available or not specified (out of scope in release) in architecture 

It is recommended that at least one type of PVR is supported by the IPTV system. 

Mandating this feature is subject to local regulatory policies. 

Advertising refers to traditional broadcast based advertising services which impose no new 

requirements on IMS based IPTV subsystem. 



The service request/response messages between the UE and the SCF are transferred via the Core IMS. Media Control 
messages are exchanged between the UE and the MCE via the Xc reference point. Media Data is exchanged between 
UE and MDF via the Xd reference point. 

For UGC services, media may also be exchanged or streamed between users provided that the control of this media 
exchange or these media streams lies with the UGC function. 

Eor CR services, the SCF exchanges service request/response messages with the UE directly over the Ut or via the IMS 
Core as appropriate. 

5.1.3 Functional entities 

Refer to clause 5.1.5. 

5.1 .3A Generic Capabilities 

IPTV Generic IPTV Capabilities: 

1 . service discovery and selection 

2. service control 

3. service interaction 

4. media control 

5. media delivery 

6. content protection 

7. content management and distribution 

8. interactions with other NGN services 

5.1.4 Elementary functions 

General: 

1 . network attachment 

2. registration 



£75/ 



21 ETSI TS 182 027 V3.4.1 (2010-06) 



3. resource Management 

4. charging information 
IPTV elementary functions: 
Service related elementary functions 

5. service discovery 

6. service authorization 

7. service selection 

8. service initiation 

9. service control 

10. service information handling (e.g. metadata) 

1 1 . service configuration 
Session related elementary functions 

12. session initiation 

13. session modification 

14. session termination 

Service Protection related elementary functions 

15. service key triggering function 

Multimedia delivery and control related elementary functions 

16. multicast based media delivery (media streaming) 

17. unicast based media delivery (media streaming) 

18. content download/upload (offline content transfer) 

19. control of multicast based media streaming 

20. control of unicast based media streaming) 

21 . control of content transfer by download/upload 

22. content ingestion (receiving content) 

23. content recording(capture of live content) 

24. content storage 

25. content adaptation (e.g. transcoding, mix, substitute, personalize) 
Content management related elementary functions 

26. content acquisition 

27. content validation 

28. content distribution 

Content protection related elementary functions 

29. content licencing 

30. content key management 
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3 1 . content encryption 



NOTE: Content protection solutions are not standardised by TISPAN but a framework allowing for 
implementation of multiple solutions is provided by the TISPAN architecture. 

User data management related elementary functions 

32. User profile/data management 

33. Accounting/right control 
IPTV Common elementary functions: 

34. Status/state (changes) detection/reporting 

35. Common notification 

36. Messaging 

37. Presence Reporting 

38. Inter-destination Media synchronization 

5.1.4.1 Content security functions 

Content security elementary functions are described in clause 10.2. 

5.1.5 Functional Entities 

5.1 .5.1 Service Discovery and Selection Functions (SDF and SSF) 

The Service Discovery Function (SDF) and Service Selection Function (SSF) are functions which provide information 
necessary to the UE to select an IPTV service. 

Tasks of the SDF: 

• Generates and/or provides the service attachment information. 

• Provides personalized service discovery. 

The service attachment information consists of SSF addresses in the form of URIs and/or ip-addresses. 
Tasks of the SSF: 

• Provides the service selection information, e.g. a list of available services that the UE can then browse and 
select. The SSF may optionally generate this service selection information. It may also retrieve and forward 
the service selection information. 

Provides personalized service selection information and/or information needed to personalize the service 
selection. This must be delivered via unicast mode. (See note 1 regarding multicast options.) 

Provides non-personalized service selection data. This can be delivered via multicast or unicast mode. 

• Optionally provides service selection presentation information. This presentation information may be 
personalized when it is delivered over unicast mode. Optionally receives selection request from UE, e.g. an 
N-PVR content capture request as described in clause 8.5. 

NOTE 1 : The way the service selection information might be personalized when it is delivered via multicast mode 
is out of scope for this release. However, specified below is a non exhaustive list of high-level options to 
achieve such personalization: 

• Using the SDF: when processing a request from a particular user/UE, the SDF could redirect the user/UE 
to specific multicast addresses/SSFs corresponding to the category to which the user belongs. This would 
imply that users/UEs are classified into specific categories. 
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• Using the SCF: UE could fetch IPTV user profile information in the form of BC Service ID listings from the 
SCF. This may be encoded as XML document(s) via the Ut reference point using XCAP-like mechanism or as 
HTML document with possibly embedded scripts to filter this service selection data. This IPTV user profile 
information may then be used to locally filter the service selection data that was previously delivered via 
multicast mode. 

NOTE 2: EPG is defined in TS 181 016 [15]. 

For each IPTV service, the following data is provided: 

• An identifier associated to the IPTV service: this identifier is used by service control functions and media 
functions to identify the requested content when processing service initiation requests. In case of a CoD 
service, the identifier identifies exactly one content item. In case of a BC service, the BC identifier, which is 
the Service Package Id related to BC profile defined in clause 7.3, identifies a set of channels among which the 
user can switch. 



• 



Optionally the set of network parameters that may be required by the UE to activate a service (e.g. the extra 
information that may be needed by the UE to establish content delivery channels and content control 
channels). 

• User readable data related to the IPTV service. 

5.1 .5.2 IPTV Service Control Functions (SCF) 

Tasks of SCF: 

• Service authorization during session initiation and session modification, which includes checking IPTV users' 
profiles in order to allow or deny access to the service. 

• Credit limit and credit control (using the on-line charging systems ES 282 010 [i.3]). 
In addition, the SCF performs the following tasks depending on type of service supported 

• Select the relevant IPTV media functions (see clause 5.2). 

• Send relevant notifications to the MF, e.g. for content recommendation service. 

• For Push CoD Services, initiate media content (e.g. recorded BC program, CoD content) download to UE. 

• Select appropriate ad content for specific user or user group, based on user profile (e.g. user preference, 
shopping habits, location information, etc.) and IPTV service status (e.g. current BC program ID, commercial 
break in BC service or pause during CoD content playback). 

• Communicate with an external advertising sub-system in order to make ad-selection and ad-placement 
decisions if one exists (see annexes E and F). 

• For SCF-managed TAI, send ad insertion indication to MF or UE. 

• Instruct the UE to perform trick play commands, e.g. pause a TV channel, CoD or N-PVR stream. 

• Initiate BC and/or CoD session to UE for immediate consumption. 

• Generate playlist information and communicate it to the MF. 

• For Content Recommendation Services, detect CRS event and generate CRS information for specific user or 
user group, based on user profile (e.g. user preference). 

• Detect an event, based on some criteria, trigger relevant internal service logic and send a notification to the UE 
or other applications associated with the specific user. 

• Optionally, for PVR service, initiate the recording of content, e.g. for C-PVR service, initiates a notification 
request to UE to start recording. 

• For restricted trick play, acquire restriction policy and transmit to relevant MF. 
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• Detecting IPTV service state information. 

• Optionally, aggregating (i.e. collecting and storing) requested IPTV service state information. 

The SCF is a SIP Application Server (AS). 

An IPTV SCF belonging to an IMS network managed by another provider shall not have direct access to user profile 
data in the UPSF via the Sh reference point; it may however have access to user profile data by other means 
(e.g. Rg reference point to GUP), depending on the NGN operator's implementation and capabilities. 

The SCF may use the IPTV profile in order to customize the user experience. For instance, the list of subscribed BC TV 
Services could be used to filter the information sent to the UE. The User Equipment communicates with the IPTV 
Service Control Functions via the Core IMS for the purpose of session management, and may be using the Ut reference 
point for the purpose of service profile configuration. In the latter case, an authentication proxy may sit between the 
User Equipment and the SCF. 

5.1 .5.3 IPTV Media Control and Delivery Functions (MCF and MDF) 

IPTV Media Functions are in charge of controlling and delivering the media flows to the UE. They are split into Media 
Control Functions (MCF) and Media Delivery Functions (MDF). 

Tasks of Media Control Function (MCF): 

Handling media flow control of MDF. 

May manage the media processing of MDF. 

Monitoring the status of MDF. 

Managing interaction with the UE (e.g trick mode commands). 

HandUng interaction with the IPTV service control function SCF. 

Keeping an accurate view on status and content distribution related to the different MDFs that it controls. 

Detecting IPTV service state information. 

Reporting IPTV service state information to SCF when requested. 

Selecting an MDF, in the case an MCF controls multiple MDFs different criteria, may be applicable (as 
described e.g. for CoD in clause 5.2). 

Selecting MF, return the selection result to SCF and Redirect sessions to the selected MF (e.g. in case the 
requested content is not available on this MF or for load balancing among MFs). 

Generate charging information, e.g. for end-user charging based on the viewed content. 

Handle ad insertion control of MDF, i.e. control the fetching of the ad content and synchronization between ad 
content and IPTV content, including accounting for delay or drift in broadcast TV schedules. 

In case of live User Generated Content consumption (TS 181 016 [15], clause A. 13), there is a direct 
relationship on the media delivery and media control levels between downstreaming and upstreaming UGC 
sessions, which both terminate at the MCF. The MCF ensures that session descriptions of the downstreaming 
and upstreaming UGC sessions match. UE's subscribed to the particular Live UGC are notified when this Live 
UGC starts. 

Tasks of MDF: 

• Handling media flows delivery (for delivering multimedia services to user). 

• Status reporting to MCF (e.g. reporting on established IPTV media streams). 

• Store of media (e.g. CoD assets) and may also store some service information stored with media for IPTV 

services. 
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• In particular, it may be used for storage for the most frequently accessed content or user specific content 

(e.g. recording PVR, Time-shift TV, BC service with Trick mode, user generated content) if the same tasks are 
not performed by UE. 

• May additionally process, encode or transcode (if required) media to different required media formats (e.g. TV 
resolution depending on terminals capabilities or user preferences). 

• May perform content protection functionalities (e.g. content encryption). 

• May support content ingestion of IPTV media. 

NOTE 1 : Ingested content can either be processed, encoded or transcoded in an MDF, or it can arrive in a suitable 
media format for delivery to UE, thus avoiding transcoding. 

• MDF may act as source for multicast streams of IPTV services e.g. BC or UGC media streams. 

• For UGC services, receiving content from UE through an upstreaming/upload media channel. 

• May collect QoE reports (e.g. from UE using Xd). 

• For Push CoD Services, handling content download (download CoD content to UE or record BC live stream 
and then download to UE). 

• Perform ad insertion during IPTV content playback, i.e. deliver ad content to the UE during the ad insertion 
time, either exclusively or in parallel with the IPTV content. 

• Recognize appropriate in-band /out-of-band Ad insertion indicators (eg-cue messages as defined in 

ITU-T Recommendation J. 181 [i.l8]), when present. These Ad insertion indicators define positions within the 
IPTV content where advertisement content can be inserted /replaced. This task may be done by coordination 
with an external advertising sub-system. 

• For personalized stream composition, the MDF may support alternative streams for use with an existing 
broadcast channel or CoD item, e.g. alternative video, audio or subtitle tracks. 

NOTE 2: To enhance QoE evaluation quality, QoE reports may additionally be collected from other sources than 
the UE. However, this is beyond the scope of the present document. 

To support QoE, the UE may send QoE reports via Xd concerning the quality of the IPTV Media Data received. 

Each IPTV Service Control Function uses the ISC reference point to communicate with the NGN Core IMS. As stated 
in TS 182 006 [2], an Application Server may originate requests to a destination without involving the S-CSCF. This 
capability should be used in case the SCF is to communicate with the media function without involving the core-IMS. 

Each corresponding IPTV Media Function communicates with the UE over Xc and Xd for Media Control and Media 
Delivery. For each service, the corresponding Media Control entities communicate with the UE on the Xc reference 
point and control the appropriate Media Data Delivery entities which send the Media Data to the UE on the Xd 
reference point. 

5.1.5.4 UPSF 

The UPSF holds the IMS user profile and possibly IPTV specific profile data (see clause 7). It communicates with 
IPTV Service Control Functions at the Sh reference points and with the Core IMS at the Cx reference point as defined 
in ES 282 007 [11]. When multiple instances of a UPSF exist, the Core IMS and the IPTV Service Control Functions 
may use the services of a Subscription Locator Function (SLF) to fetch the address of the UPSF. The SLF 
communicates with IPTV Service Control Functions at the Dh reference points and with the Core IMS at the Dx 
reference point as defined in ES 282 007 [11]. For the sake of simplicity the SLF and associated reference points are not 
shown on figure 2. 

NOTE: The IMS principle procedures, such as security, authentication process, are also considered to be applied 
to this IPTV functional architecture and the procedures, unless explicitly stated otherwise. 

5.1 .5.5 Transport processing functions 

IPTV services make use of generic transport processing functions defined in ES 282 001 [1]. 
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5.2 Interactions between Service Control function and Media 
Functions 

The relationship between Service Control Function (SCF) and Media Function (MF), composed of Media Control 
Function and Media Delivery Function, is shown in figure 3. 



MF 




Figure 3: Relationship between Service Control Function and Media Functions 

When an MF is involved in a session (e.g. CoD) the specific MF for this particular session will be determined during 
the session initiation and resource allocation procedure. This determination may be based on the following criteria: 

• Location of the UE. 

• Status information of all the available media functions (e.g. online or offline, media processing capabiUty, 
available resources in the different -MF holding the same contents, etc.). 

• Load of the different MF holding the same contents. 

• Content identity of the requested content; It is recommended that the structure of the content identifiers be 
designed so as to facilitate this selection, without requiring parsing the full identifier. 

The selection process relies on elementary functions that can be hosted in an SCF and/or an MCF. In the latter case the 
MCF may act as a redirect server to redirect sessions to another MCF. And in some cases, the selection task of SCF 
and/or MCF may become very simple. For e.g. if a Request-URI for service/content identifier corresponds to just one 
MCF, then SCF and/or MCF may just transfer the session to the unique MCF. 

NOTE 1 : The location of the selection process in a separate entity is out of scope for this release. 

NOTE 2: Admission control procedures for use of transport resources at the CoD-MF side are out of scope for this 
release. 

The SCF shall contact the MCF during the session initiation and resource allocation phase. The SCF may contact 
several MCFs before its determination. TheSCF contacts the MCF via the Core IMS as shown in figure 4. 
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Figure 4: Reference points between SCF and IVICF 

When the MCF is contacted, it shall respond with the parameters offer for the session corresponding to the content 
required by the UE. 

The MCF controls one or several MDFs. Tasks of the MCF are the following: 

• Select an MDF. 

• Control the media stream resources in the MDFs. 

• Interpret information coming from the SCF and control the MDFs accordingly. 

• Generate of CDRs. 

Selection of the MDF by the MCF uses similar criteria to the selection of a MCF by a SCF. And in some cases, the 
selection task of MCF may become very simple. For e.g. if a Request-URI for service/content identifier corresponds to 
just one MDF, then MCF may just transfer the session to the unique MDF. After the MCF has selected a MDF for 
service, it may communicate with the MDF. If the MDF is not functional for some reason, the MCF may detect this 
exception, for example, by a local response timeout, and select another MDF with the requested content. If there is no 
other MDF with the requested content under the MCF's control, it should redirect the service request to another MCF or 
return an appropriate error message to the SCF. 



5.3 



Void 



5.4 Inter-destination media synchronization 

Inter-destination media synchronization is an optional generic capability, aimed at servicing requiring this capability, 
see TS 181 016 [15], clause A. 9. 6 for examples. The Media Synchronization Application Server (MSAS) and 
Synchronization Client (SC) are functions that provide inter-destination media synchronization. These functions are 
used for synchronization sensitive services for which IPTV delays and delay differences may spoil the quality of 
experience. The functional entities and reference point of the synchronization mechanism are shown in figure 4A. 
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Figure 4A: Functional entities and reference points for inter-destination media synchronization 

5.4.1 Functional entities MSAS and SC 

The inter-destination synchronization mechanism uses the concept of synchronization sessions. Each synchronization 
session involves a Media Synchronization AppHcation Server (MSAS) and muhiple Synchronization Clients (SC). A 
synchronization session is used for the inter-destination synchronization of IPTV content (a BC channel, CoD, UGC, 
etc.) by exchanging synchronization status information and synchronization settings instructions. 

• Synchronization status information: timing information on media reception at each SC. 

• Synchronization settings instruction; instruction how much an SC should delay the BC channel. 
Tasks of the SC: 

• Setting up and accepting synchronization sessions with/from the MSAS. 

• Sending synchronization status information to the MSAS. 

• Receiving synchronization settings instructions from the MSAS. 

• Delaying a media stream according to the received synchronization settings instruction. 
Tasks of the MSAS: 

• Setting up and accepting synchronization sessions with/from SCs. 

• Collecting synchronization status information from SCs. 

• Calculating synchronization settings instructions for the SCs. 

• Distributing synchronization settings instructions to SCs. 

NOTE: Examples of algorithms to calculate the synchronization settings instructions from collected 
synchronization status information may be found in [i. 1 1]. 

5.4.2 Mapping onto tine IPTV architecture 

The synchronization architecture can be mapped onto the IPTV architecture in the following ways. 
Mapping 1: SC in UE 

• The MSAS is an elementai-y function of the SCF. 

• The SC is an elementary function of the UE. 

• The Sync reference point is tunnelled over the Gm and ISC reference points. 

• Each synchronization session is associated with an IPTV session. 
Mapping 2: SC in Transport 

• The MSAS is an elementary function of the SCF or a stand-alone Application Server. 
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• The SC is an elementary function of the Transport Functions. 

NOTE 1 : Mapping 1 is aimed at small-scale deployments of services that require media synchronization and only a 
limited number of UEs uses media synchronization. It reuses existing IPTV sessions. Mapping 2 is aimed 
at large-scale deployment of media synchronization. 

NOTE 2: In mapping 2, the SC is an adjunct function that may be co-resident with any of the appropriate elements 
in the transport layer. 

5.4.3 Modification and re-origination of media streams 

In addition to inter-destination media synchronization, additional synchronisation measures are needed in case a media 
stream is modified or re-originated during transport. Examples of these are transcoding, HD-to-SD conversion and 
user-generated comments to a live broadcast. In such cases, additional media-stream-modifying Synchronisation 
Clients (SC) are placed at the functional entities where media streams are modified, see figure 4B. The Sync' reference 
point is used to exchange convey synchronization status correlation information between from the 
media-stream-modifying SC and to the MSAS on the synchronicity relationship between incoming and outgoing media 
streams. 

• Synchronization correlation information: timing information on the synchronicity relationship between 
incoming and outgoing media streams at an SC. 



MSAS 



Sync 



IVIedia stream 
destination 

(e.g. UEorlFP) 



Sync' 



SC 



IVIedia stream 
modification 

(e.g. transcoder at MF 
or re-origination at UE) 



Media stream 
origination 

(e.g. I\^F or EFF) 



Media stream M 



Media stream M' 



Figure 4B: Media synchronization in case of media stream modification 
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5.5 IPTV Service State 

5.5.1 General 

IPTV service states is defined as a snapshot of the information related to an ongoing IPTV service, see clause 3.1. 
Examples include the current BC program ID, the ID of current CoD content, the state of PVR recordings, the media 
state of services and invoked trick play events, commercial breaks in services and combinations of these. 

Maintaining the IPTV service state can provide information about ongoing services towards the user and network 
elements, can support service interaction and the creation of combined services by associating service states and 
reacting on state transitions. 

IPTV service state is used in several procedures, among which are: targeted ad-insertion (see clause 8.14), shared 
service control (see clause 8.21) and event-handling involving the SCF (see clause 9.4). IPTV service state can be 
detected by SCF, MP and/or UE, aggregated by the SCF and is maintained in the IPTV Service State Data (see 
clause 7.7). 

IPTV Service State Data can be updated using the procedures in clause 8.26. 

5.5.2 Relationship between IPTV Service State and IPTV presence 

Generally, a hierarchical relation exists between the internal service states of Functional Elements, the IPTV Service 
State information and Presence information; the internal service state information can be aggregated in IPTV Service 
State, and IPTV Service State data can be used to update Presence. 

6 Reference points 

6.1 UE-SSF(Xa) 

This reference point between UE and SSF is used by the UE to make appropriate service selections. 

6.2 UE - IPTV Service Control Functions (Ut) 

This reference point between UE and IPTV Service Control Functions is used by the UE for the purpose of service 
profile configuration. 

Use of the Ut reference point conforms to ES 282 007 [11]. 

6.3 UE - Core IIVIS (Gm) 

Use of the Gm reference point conforms to ES 282 007 [11]. 

6.4 UE - IVIedia Control Functions (Xc) 

This Xc reference point (for media control) is a logical end-to-end reference point between the UE and the IPTV Media 
Control Function that is used to exchange media control messages for controlling the IPTV Media flow. 

NOTE: Transport related reference points are used to carry media control messages over underlaying transport 
segment (defined in ES 282 001 [1]) and as shown below in figure 5 depending on the location of the 
MCF. The Dj reference point between the UE and the access network, the Di reference point between the 
access network and the core network, and possibly the Ds or Iz reference point between the core network 
and the Media Control Function if the MCF is located after the Core Network. 
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Figure 5: Decomposition of the Xc reference point when the IVICF is after the core networit 



6.5 UE - Media Delivery Functions (Xd) 

This Xd reference point (for media delivery) is a logical end-to-end reference point between the UE and the IPTV 
Media Delivery Function that is used to deliver media data. 



NOTE: 



Transport related reference points are used to carry media delivery data over underlaying transport 
segment (defined in ES 282 001 [1]) and as shown below in figure 6 depending on the location of 
the MDF. The Dj reference point between the UE and the access network, the Di reference point 
between the access network and the core network, and possibly the Ds or Iz reference point 
between the core network and the Media Delivery Function if the MDF is located after the Core 
Network. 




Figure 6: Decomposition of the Xd reference point 

If the IPTV system architecture supports QoS and/or QoE [7] and [i.l], this reference point may carry QoS and/or QoE 
reports from the UE to the MDF. These reports relate to the quality of the IPTV Media Data that the UE receives. 

6.6 IPTV Service Control Functions (SCF) - UPSF (Sh) 

Use of the Sh reference point conforms to ES 282 007 [11]. 

6.7 Core IMS - UPSF (Cx) 

Use of the Cx reference point conforms to ES 282 007 [11]. 

6.8 Core IMS - IPTV Service Control Functions (ISC) 

Use of the ISC reference point conforms to ES 282 007 [11]. 

6.9 Core IMS - IPTV Media Functions (y2) 

This reference point between S-CSCF and IPTV Media Control Function (MCF) carries IPTV Service Control 
Signalling originating from the IPTV Service Control Function (SCF) to control the MCF. 

In case the CSCF and the Media Control Function are in different administrative domains, signalling flows go through 
an IBCF. 
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NOTE: As stated in TS 182 006 [2], an Application Server may originate requests to a destination without 

involving the S-CSCF. This capability should be used in case the SCF is to communicate with the media 
function without involving the core-IMS, thus omitting y2. 

6.10 Core IMS - SDF (ISC) 

Use of the ISC reference point conforms to ES 282 007 [11]. 

6.11 SDF-UPSF(Sh) 

Use of the Sh reference point conforms to ES 282 007 [11]. 

6.12 Void 

Void. 

6.13 Application Functions - MASS (e2) 

Use of the e2 reference point conforms to ES 282 007 [11] and ES 282 004 [3]. 

NOTE: Application Function entities associated to IPTV services such as core IMS and SCF may query the UE 
location from the CLE in order to fulfil their tasks. 

6.14 Core IMS - RACS (Gq') 

Use of the Gq' reference point conforms to ES 282 007 [1 1] and ES 282 003 [8]. 

6.15 MASS - RACS (e4) 

Use of the e4 reference point conforms to ES 282 003 [8] and ES 282 004 [3]. 

6.16 IPTV Service Control Functions - SLF (Dh) 

Use of the Dh reference point conforms to ES 282 007 [11]. 

6.17 Core IMS - SLF (Dx) 

Use of the Dx reference point conforms to ES 282 007 [11]. 

6.18 IPTV Media Control Function - IPTV Media Delivery 
Function (Xp) 

This Xp reference point between the Media Control Function (MCE) and Media Delivery Function is used to control 
media delivery sessions to support media delivery session setup when content is distributed across one and more media 
delivery functions. 
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6.19 MSAS-SC reference point (Sync) 

This optional reference point is between Media Synchronization Application Server (MSAS) and 
media-stream-synchronizing Synchronization Client (SC). It is used to set up synchronization sessions and to exchange 
synchronization status information and synchronization settings instructions with functional entities in the network 
where media streams are mutually synchronized. The Sync reference point is a logical reference point in Mapping 1 
from clause 5.4.2, where it is tunnelled over the Gm and ISC reference points. 

6.20 MSAS-SC reference point (Sync') 

This optional reference point is between Media Synchronization Application Server (MSAS) and 
media-stream-modifying Synchronization Client (SC). It is used to set up synchronization sessions and to exchange 
synchronization status information with functional entities in the network where to-be-synchronized media streams are 
modified. 

6.21 SSF-SCF reference point (Ss') 

The Ss' optional reference point between IPTV SCF and SSF is used to exchange required service information and/or 
service provider information(e.g. service provider details, UGC specific information, etc. 

NOTE 1: Since SSF is not designed for content metadata maintenance/management. How the content metadata is 
managed in the IPTV architecture and whether there should be required for metadata management any 
extension of SSF functionality or new functional entity or can be handle by IPTV management is out 
scope of the present document, which may be considered in future release. 

NOTE 2: The optional Ss' reference point is not standardised in the current release. 



7 User data 

7.1 Classification of information 

Five categories of user data are involved in providing IPTV services: 

1. IMS-profile: This category includes all information required to establish IMS sessions and access IPTV services 
hosted in Application Servers, as described in TR 182 005 [i.4]. 

2. Communication Services profile: This category encompasses all information associated to communication 
services (e.g. PSTN/ISDN simulation services, presence services, messaging services...) as defined in relevant 
ETSI TISPAN standards (e.g. TS 183 004 [9]). This type of information is required in support of combinational 
services (e.g. Caller Id on TV Screen). 

3. IPTV user profile: This category encompasses all information required to operate an IPTV service. This 
includes all the user settings regarding: 

Global settings (Language preference, etc.). 

Broadcast settings. 

List of subscribed BC service packages. A BC service package is a set of elementary BC TV services, 
along with a description. These BC services have the same authorization and charging policy. A BC 
IPTV service is for instance a multicast channel, interactive channel, mosaic that a user may subscribe to. 

NOTE: The Broadcast settings only provide a reference to service package and/or associated services that a given 
IPTV user has subscribed to and is not meant to be a complete description of the service package and/or 
service. The complete service package and/or service description is available in an associated IPTV 
Service Profile definition (e.g. described with metadata). If the list of elementary IPTV services 
associated with a given service package are not explicitly listed in the IPTV user profile, then it implies 
that the IPTV user has implicitly subscribed to all of the IPTV services within that service package. 
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IPTV User profile information may be used for providing a listing of recommended content to the user 
based on the user's profile settings 

Content on demand settings (Parental control level, etc.). 

PVR settings (PVR preferences network/local, PVR user restrictions, PVR storage limit). 

UE Settings which includes information related to the capabilities of the UE(s) that an IPTV user is 
associated with. An IPTV user may be associated with one or more UE(s) and every UE is uniquely 
identified with a unique UE Identifier (UE ID). The UE capabilities associated with an IPTV user profile 
may be used for customization of IPTV service selection data that is provided by the SSF to the IPTV 
user (based on capabilities of the UE that the IPTV user is currently associated with). For instance, an 
IPTV user on a SD-only device would not be provided with information related to HD services. 

The UE settings is not intended to cover all information related to the UE and currently holds only the 
UE capabilities attribute since this information may be used by the SSF for personalized service 
selection. Note that detailed information about the UE may be located elsewhere and can be referenced 
by the IPTV user profile using the UE ID parameter. 

The "user actions recordable" parameter indicates whether user actions can be recorded by the network 
as part of the IPTV service action data, see clause 7.3.1.5. 

Further details are provided in clause 7.3. 

4. IPTV service action data: see clause 7.4. 

5. IPTV Service State Data: see clause 7.7. 

The relationships between the IMS profile and the dedicated IPTV user data categories are as follows: 

IPTV user profile: This profile is associated with an IMS Public user Identity (IMPU). This would enable 
for instance enforcement of parental control on a per-user basis independent of the device they are using. 

IPTV service action data: This profile is associated with an IMS Public user Identity (IMPU). This would 
enable for instance "follow me TV/video" kind of scenarios wherein users can resume the viewing of 
content on any device that they are authorized to use. 

IPTV Service State Data: This information is associated with an IMS Public user Identity (IMPU). This 
would enable (IPTV, non-IPTV and blended) services that interact with IPTV service state, for example 
incoming call management (clause 9.2) and shared service control (clause 8.21). 

7.2 Location and access to user data 

The user data is located in UPSF or in more functions/locations as described in clause 7.2.1. When all user data is stored 
in the UPSF only, as transparent data associated to Application Server functions then this approach is referred to as the 
consolidated approach. If user data is stored at multiple locations and distributed across several functions (e.g. 
application servers, stand-alone severs associated with one or more AS) then this approach is referred to as federated 
approach. 

7.2.1 Data management functions 

IMS-profile information is managed by the UPSF. Communication Services profile information may be managed by 
dedicated database functions, the Application Server functions hosting the communication services, or by the UPSF as 
transparent data (repository function) associated to these Application Server functions. In the first and second case the 
Application Server function or the stand-alone server may exhibit the behaviour of an XDMS. 

IPTV user profile information should be located in the following locations: 

• Application Server functions hosting the IPTV applications. 

• In a stand-alone server associated with one or more Application Server functions. 

• In the UPSF as transparent data associated to these Application Server functions. 
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The first and second options are recommended for data to be accessed by 3rd party application server functions. In the 
first and second case the AppHcation Server function or the stand-alone server may exhibit the behaviour of an XDMS. 

IPTV service action data as well as content markers data need to be persistent across IPTV sessions, and should be 
located in the network. They may be located in one of the following locations 

• The Application Server functions hosting the IPTV applications. 

• A stand-alone server associated with one or more Application Server functions. 

• In the UPSF as transparent data associated to these Application Server functions. 

In the first and second case the Application Server function or the stand-alone server may exhibit the behaviour of an 
XDMS. 

IPTV service state data relate to ongoing IPTV session(s). The information may be stored in one of the following 
locations: 

• The Application Server functions hosting the IPTV applications. 

• A stand-alone server associated with one or more Application Server functions. 

• In the UPSF as transparent data associated to these Application Server functions. 

In the first and second case the Application Server function or the stand-alone server may exhibit the behaviour of an 
XDMS. 

7.2.2 Access from other application servers 

User data stored in the UPSF can be accessed by Application Servers at the Sh reference point. 

Direct access to user data stored in Application Servers is outside the scope of the present document. However, part of 
these data may be indirectly exposed through Web Services and/or SIP Event packages. 

7.2.3 Access from User Equipment (UE) 

A subset of IPTV user-profile information may be accessed from the User Equipment at the Ut reference point. 

7.2.4 Access from tine SSF 

For the purpose of personalized service selection, the SSF may need to access user data. 

In the case when such user data is stored in the UPSF, it can be accessed by the SSF at the Sh reference point when the 
SSF is in the same domain. 

On the contrary, when such user data is stored in the AS or in a stand alone server associated with one or more 
application servers or if the SSF in not in the same domain as the UPSF, the user data can be accessed by the SSF using 
an reference point that is out of scope for this release. 

The SSF may also request notification of IPTV user data updates. 

7.3 IPTV user profile structure 
7.3.1 IPTV user profile structure 

An IPTV user profile comprises: 

• zero, one or more instances of the UE object class comprising UE capabilities attribute and associated UE ID; 

• at least one instance of a Broadcast (BC) or a Content on Demand (CoD) object class (see figure 7); 

• zero or one instance of the Global settings object class; 
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• zero or one instance of the Personal Video Recorder (PVR) object class; 

• zero, one or multiple instances of Personalized Channel profile (PCh Profile) object class; 

• zero or one instance of the Content Recommendation settings (CR) object class; 

• zero or one instance of the Incoming Call Management settings (ICM) object class. 

A Broadcast profile comprises one or more BC Service package descriptions. 

A PCh profile comprises one or more PCh itemlist descriptions, which contain the mapping of each PCh content item to 
the world clockthe individual PCh IDs as well as the expiry time of each PCh list. 

Each BC service package comprises zero or more BC TV Services descriptions. 

Each PCh list comprises one or more PCh items descriptions. 

Each BC TV service includes a quality definition level (e.g. standard or high definition or other defined quality level). 
Delivered quality level depends on this quality definition level as well as UE capabilities, available codecs and/or 
bandwidth limitations. 

NOTE: When there is no service description for a given BC service package, it would imply that the IPTV user 
has access to all of the BC services within that given BC service package. 

The complete service package and/or service description is available in an associated IPTV Service Profile definition 
(e.g. described with metadata). The ServicePackageld attribute associated with the service package and/or the Serviceld 
attribute associated with the service refers to appropriate descriptions in an associated IPTV Service Profile definition 
(e.g. described with metadata) and hence, can be used to fetch detailed information about the particular service package 
and associated services. 

A CoD profile includes a parental control level (ParentalControlLevel) attribute. 

A BC profile includes a parental control level (ParentalControlLevel) attribute. 

An PVR profile contains PVR rules for the user. 

A Global Setting profile includes zero or one Parental Control description, which contains attributes related to parental 
control. 

The CR Settings includes a CR notification attributes. 

The ICM Settings includes ICMrule attributes. 
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Figure 7: IPTV user profile data model 

This data model assumes that each IPTV user is allocated at least an IMS Public User Identity and an IPTV user profile 
is associated with this IMS Public User Identity. 

Multiple IPTV users may share the same IMS subscription. 

The IPTV user identity (i.e. the IMS Public User Identity) selected when making an outgoing request is asserted by the 
UE using means outside the scope of the present document (e.g. using a local pin code). 

7.3.1 .1 BC service package 

A service package is a group of one or more BC service. 

7.3.1.2 BC service 

A service relates to a particular TV channel and associated quality definition (e.g. SD or HD). 

7.3.1.3 UE 

Contains the UE's Id and its capabilities. 

7.3.1 .4 Global settings: language preference 

This attribute defines which default language the user would like to use. For instance, this could be the default language 
for the GUI that is displayed on the UE, and/or the default language used for subtitles. 
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7.3.1 .5 Global settings: user action recordable 

The "user actions recordable" parameter indicates whether user actions can be recorded by the network as part of the 
IPTV service action data. 

7.3.1 .5A Global settings: PG-GostLimit 

This parameter defines the cost Hmit of an individual content when toll content (e.g. PPV content) is involved. It has a 
string value. 

7.3.1 .5B Global settings: PG-TotalGostLimit 

This parameter defines the cost limit on all IPTV content over a period of time. It has a string value. 
This parameter may be defined on the basis of day, week, month or year. 
There can be several occurrences of this parameter. 

7.3.1.5G Global settings: PC-Classification Restriction 

This parameter defines the classifications of the content (e.g. news, action movies, parental rating, ...) which are not 
allowed, in case of Parental Control. It has an enumerated value. 

7.3.1.5D Global settings: PC-TlmePeriodRestriction 

This parameter defines time period of the day, in case of Parental Control, during which all IPTV services are restricted. 
It has a time segment value, which includes a start time and a time length. 

There can be several occurrences of this parameter. 

7.3.1 .5E Global settings: PC-TotalPlayTimeLimit 

This parameter defines the total play time which can be consumed for IPTV services, in case of Parental Control. It has 
a string value. 

This parameter may be defined on the basis of day or week. 

7.3.1 .5F Global settings: PC-AdminUser 

The "PC-AdminUser " parameter defines a list of administrative users (identified by a SIP-URI) that have access to the 
user's profile and can modify it. 

Only the users indicated in this list have the rights to change PC related parameters in the profile. 

7.3.1 .5G Global settings: dynamic PC-activation 

The " dynamic PC-activation " parameter indicates whether dynamic parental control is activated or not. If activated, 
any session initiation request that does not suit the parental-control rules well, will trigger a request to the contact 
defined in the "PC-Contact" parameter. 

7.3.1 .5H Global settings: PC-Contact 

The "PC -Contact" parameter indicates a list of users (SIP URI or mobile phone number) to be contacted at session 
initiation request if dynamic PC-activation is on. 

NOTE: Parental control related parameters in Global Settings object class can be optionally and dynamically 
configured according to user strategy. 



£75/ 



39 ETSI TS 182 027 V3.4.1 (2010-06) 

7.3.1.6 N-PVR storage-limit 

This attribute defines a limit allocated per user for N-PVR contents. 

It can be expressed in time or volume. 

There can be several occurrences of this parameter. 

7.3.1.6A PVR: IPTVContentMarkerAuthorizedViewUser 

The "IPTVContentMarkerAuthorizedViewUser" parameter indicates a list of users authorized to view PVR IPTV 
Content Markers of this user. The data model of IPTV Content Markers is defined in clause 7.5. 

7.3.1.6B PVR: IPTVContentMarkerSourceUser 

The "IPTVContentMarkerSourceUser" parameter indicates a list of other users from which PVR IPTV Content Markers 
can be accessed. The data model of IPTV Content Markers is defined in clause 7.5. 

NOTE: The authorization to access a user's IPTV Content Markers does not imply access rights to the content. 
Separate acquisition of these rights might be necessary. 

7.3.1 .6C PVR: AuthorizedControlUser 

The "AuthorizedControlUser" parameter indicates a list of users authorized to initiate the PVR capture request on behalf 
of this user. 

7.3.1.7 BC: ParentalControlLevel 

This parameter defines the Parental Control Level of the BC services. It has an enumerated value. 

7.3.1.7A BC: IPTVContentMarkerAuthorizedViewUser 

The "IPTVContentMarkerAuthorizedViewUser" parameter indicates a list of users authorized to view BC IPTV 
Content Markers of this user. The data model of IPTV Content Markers is defined in clause 7.5. 

7.3.1.7B BC: IPTVContentMarkerSourceUser 

The "IPTVContentMarkerSourceUser" parameter indicates a list of other users from which BC IPTV Content Markers 
can be accessed. The data model of IPTV Content Markers is defined in clause 7.5. 

NOTE: The authorization to access a user's IPTV Content Markers does not imply access rights to the content. 
Separate acquisition of these rights might be necessary. 

7.3.1.8 CoD: IPTVContentMarkerAuthorizedViewUser 

The "IPTVContentMarkerAuthorizedViewUser" parameter indicates a list of users authorized to view CoD IPTV 
Content Markers of this user. The data model of IPTV Content Markers is defined in clause 7.5. 

7.3.1.9 CoD: IPTVContentMarkerSourceUser 

The "IPTVContentMarkerSourceUser" parameter indicates a list of other users from which CoD IPTV Content Markers 
can be accessed. The data model of IPTV Content Markers is defined in clause 7.5. 

NOTE: The authorization to access a user's IPTV Content Markers does not imply access rights to the content. 
Separate acquisition of these rights might be necessary. 

7.3.1.10 PCh:PChld 

This attribute contains the unique identifier of the PCh list. It has a string value. 
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7.3.1 .11 PCh: PChExpiryTime 

This attribute defines the expiry time of the PCh list. It has a timestamp value. 

7.3.1.12 PCh: PChltemServiceType 

This attribute defines the service type of the item within a PCh list. It has an enumerated value and refers to BC, CoD or 
N-PVR. 

7.3.1.13 PCh: PChltemContentId 

This attribute defines the referenced content id of the item within a PCh list: 

• In case of BC, it shall consist of the "BCServiceld" as well as the "Programmeld" (see clause 7.4.1). 

• In case of CoD, it shall be set to the "CoDId" (see clause 7.4.1). 

• In case of N-PVR, it shall be set to the "N-PVRContentId" (see clause 7.4. 1). 

7.3.1.14 PCh: PChltemStartTime 

This attribute indicates the start time of playing a content item within a PCh list. It has a timestamp value. 

7.3.1.15 PCh: PCh Item EndTime 

This attribute indicates the end time of playing a content item within a PCh list. It has a timestamp value. 

7.3.1.16 PCh: PChltemOffset 

This optional attribute indicates the offset from beginning of the content item in case the item is CoD or N-PVR., from 
which the item is ready to play. It has a timestamp value. If this attribute is not present, the item shall be played from 
the beginning. 

NOTE: The availability of PCh information should be guaranteed by mechanisms aligned with user profile and 
content metadata validity rules. 

7.3.1 .17 CR Settings: CR notifications 

Activate, deactivate content recommendation notifications, or other actions for further study. 

7.3.1.18 UGC storage-limit 

This attribute defines a limit allocated per user for UGC contents. 
It can be expressed in time or volume. 

7.3.1 .19 UGC: AuthorizedControlUser 

The "AuthorizedControlUser" parameter indicates a list of users authorized to activate the target UE remotely for 
initiation of the UGC service. 

7.3.1 .20 ICM Settings: ICM rules 

This attribute allows the user to set the behaviour of its IPTV service when combined with telephony services. 

It defines the behaviour of the IPTV service when user is receiving an incoming call, i.e. accept on TV, on phone, 
refuse, pause on incoming call (using network-controlled trick play from clause 8. 16) or redirect the call to voicemail. 

NOTE: further actions are beyond the scope of this release. 
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7.3.2 Usage of IPTV user profile 

The IPTV user profile may be used to customize the user IPTV experience. 
For instance: 

• The CoD profile parental control level should be used to filter a CoD catalog. 

• The UE capabilities associated with an IPTV user profile UE data may be used for customization of IPTV 
service selection data that is provided by the SSF to the IPTV user (based on capabilities of the UE that the 
IPTV user is currently associated with). 

Thanks to the IPTV user profile standardization, any equipment can render the same IPTV environment to the user. The 
IPTV user profile may also be used to allow or deny access to IPTV services. 

7.3.3 Life cycle 

UE List: The information about the UE(s) that an IPTV user is currently associated with may be purged when the IPTV 
user deregisters and/or logs off. This is to avoid persisting UE related information when the IPTV user logs off that 
particular UE. 

7.4 IPTV service action data 
7.4.0 General 

IPTV service action data: this category encompasses information related to the actions the user may have taken while 
accessing services such as BC or CoD (e.g. ordering a CoD - Choosing to pause while viewing a live event). Those data 
are required to enable IPTV session portability for the user. This category also comprises IPTV service state 
information (e.g. current BC program ID, commercial break in BC service, pause during CoD playback, list of CoDs 
and associated status, record status of recordings, trick play events). 

The recipient of the IPTV service action data shall ensure they comply with the data protection regulations that apply in 
the authorized jurisdiction that the service is delivered (see also TS 187 016 [19]). 
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7.4.1 Data model 



IPTV Service Action 



ActionData Id: string 



-<>- 



0..n 



0..n 



BC Bookmarks 



BCServiceld: stiing 
Programmeld: string 
Bookmark: tiinestamp 
BookmarkExpiryTime: timestamp 



NPVR items 



NPVRContentId: string 
BCServiceld: string 
RecordStartDate: timestamp 
RecordEndDate: timestamp 
RecordDescription: string 
RecordStatus: enumerated 
RecordOffset: string 
RecordOffsetExpiryTime timestamp 
RecordExpiryTime: timestamp 



0..n 



UGC items 



UGCContentId: string 
UGCCreationTime: timestamp 
UGCTargetUserld: string 
UGCGenre : string 
UGCTitle: string 
UGCOri ginator : strin g 
UGCDescription: string 
UGCAuthorizedViewUser: string 



0..n 



CPVR items 



CPVRContentId: string 
BCServiceld: string 
TargetUEId: string 
RecordStartDate: timestamp 
RecordEndDate: timestamp 
RecordDescription: string 



0..n 



Available CoD 



CoDId: string 

CoDDeliveryStatus: enuinerated 
CoDOffset: string 
CoDOffsetExpiryTime: timestamp 



Figure 8: IPTV Service action data - data model 

This data model assumes that each IPTV user is allocated at least an IMS Public User Identity and an IPTV Service 
Action data profile is associated with this IMS Public User Identity. 

NOTE 1 : The "Programmeld" attribute is unique, as it refers to one and only one entry in the EPG. 

NOTE 2: Although the "Bookmark" attribute could be used as an indirect way to identify the programme, it is seen 
as more convenient and immediate to use the Programmeld for that purpose. 

IPTV service action data includes the following information: 

• The list of CoDs that the user has ordered and associated status, CodOffset which is offset in the content where 
the user has paused and CodOffsetExpiryTime which is expiration time associated with the CodOffset value. 
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• The list of BC TV services (or programmes) that the user has paused (and is hence likely to resume later) 
including the bookmark value associated with the paused BC TV service or Programme and 
BookMarkExpiryTime which is expiration time associated with the bookmark value. 

• The list of N-PVR contents that the user has asked to be recorded. This would include the following 
parameters: 

N-PVRContentId: it refers to a content identifier used by the UE to activate an N-PVR session related to 
the N-PVR content. 

NOTE 3: In the case when a specific programme has been requested to be recorded, this ID would be the same as 
ProgrammelD, and the RecordStartDate and RecordEndDate attributes would be optional. 

BCServiceld: the identifier of the BC service that is to be recorded. 

(Optionally) RecordStartDate: the start date (and time) of the recording. 

(Optionally) RecordEndDate: the end date (and time) of the recording. 

(Optionally) RecordDescription: a description of the recording made by the user when he/she requested 
to record the live content. 

RecordStatus: the status of such a recording (requested - scheduled - available - failed). 

RecordOffset: the offset in the N-PVR content where the user might have paused while actually watching 
it. 

RecordOffsetExpiryTime: expiration time associated with the RecordOffset. 

RecordExpiryTime: the expiration time associated with the recording value. 

• The list of C-PVR contents that the user has asked to be recorded. This would include the following 
parameters: 

BCServiceld: the identifier of the BC service that is to be recorded. 

TargetUEId: the identifier of Target UE which stores the content. 

(Optional) C-PVRContentId: the identifier of the C-PVR content, can be used as an index for user. 

NOTE 4: In the case when a specific programme has been requested to be recorded, this ID would be the same as 
ProgrammelD, and the RecordStartDate and RecordEndDate attributes would be optional. 

(Optional) RecordStartDate: the start date (and time) of the recording. 

(Optional) RecordEndDate: the end date (and time) of the recording. 

(Optional) RecordDescription: a description of the recording made by the user when he/she requested to 
record the live content. 

RecordStatus: the status of such a recording (requested - scheduled - available - failed). 



7.4.2 Life cycle 



CoD list: Items may be removed when they are no longer accessible (e.g. the offer they were attached to has 
expired.) or when the entitled number of visualizations has been reached. Alternatively, items are purged when 
the expiration time associated with the CoDOffset (identified using CoDOffserExpiryTime) expires. 

BC bookmarks are kept in the profile while the BC TV service or Programme they refer to is available in the 
media server. Alternatively, entries may also be purged when the expiration time associated with BookMark 
value (identified using BookmarkExpiryTime) expires. 

N-PVR items are kept in the profile while the content they refer to is available in the Network PVR server(s). 
Alternatively, entries may also be purged when the expiration time associated with Recording value (identified 
using RecordExpiryTime) expires. Failed recordings may be purged on a regular configurable basis. 
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7.5 IPTV information storing/sharing services 

7.5.1 General 

This clause defines data models to be used by IPTV information sharing or targeting services. 

NOTE: Accessibility, as well as the legal use of data related to sharing or targeted services should be considered. 

7.5.2 IPTV Content IVIarker 



7.5.2.1 



General 



This clause defines the data model of IPTV Content Markers for BC/CoD/N-PVR services. The intention of IPTV 
Content Markers is twofold: 

1) To store configurable pointers to content and be able to quickly access that content. 

2) Enable users to exchange and share IPTV Content Markers. 

NOTE: Exchanging IPTV Content Markers between users does not imply a transfer of access rights. Separate 
acquisition of these rights might be necessary. 



IPTV Content Marker 



IPTVContentMarkerlD: String 
OwnerUserlD: String 
IPTV service type identifier: String 
IPTV content identifier: String 
StartTimeOflPTVContentMarker: timestamp 
EndTimeOf I PTVContentMarker: timestamp 
UserComment: String 
GenerationTime: timestamp 
ExpiryTime: timestamp 



Figure 8A: IPTV Content Marker - data model 

Figure 8A depicts the data model assumes that each IPTV user is allocated at least an IMS Public User Identity and 
individual IPTV Bookmark data items are associated with this IMS Public User Identity. 

Each of the entries within an IPTV Bookmark item may be rendered to the end-user. 

Concerning life cycle, items may be removed when the content they refer to does no longer exist. Alternatively, items 
are purged when the expiration time associated with the content marker (identified using ExpiryTime) expires. 

7.5.2.2 IPTVGontentlVlarkerlD 

Unique identifier to distinguish between several of a user's IPTV Content Markers. It shall always be present. 

7.5.2.3 OwnerUserlD 

This attribute shall identify the user owning the IPTV Content Marker by means of the IMPU. It shall always be 
present. 
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7.5.2.4 IPTV service type identifier 

This attribute identifies the type of IPTV service this IPTV Content Marker refers to, see clause 1.2. 

7.5.2.5 IPTV Content Identifier 

This attribute shall identify the content this particular IPTV Content Marker refers to, as specified in clause 1. 1 . 

• In case of BC, it shall consist of the "BCServiceld" as well as the "Programmeld" (see clause 7.4.1) 

7.5.2.6 StartTimeOflPTVContentMarker 

This optional timestamp may be used to identify a starting point for playback of referred-to content. If it is not present 
playback should start at the beginning of the content. 

NOTE: StartTimeOflPTVContentMarker and EndTimeOflPTVContentMarker are intended as guidance for 
playback logic to point to particularly interesting scenes within the content they are associated to. 

7.5.2.7 EndTimeOflPTVContentMarker 

This optional timestamp may be used to identify an ending point for playback of referred-to content. If it is not present 
playback should end at the end of the content. 

NOTE: StartTimeOflPTVContentMarker and EndTimeOflPTVContentMarker are intended as guidance for 
playback logic to point to particularly interesting scenes within the content they are associated to. 

7.5.2.8 UserComment 

The user may comment an IPTV Content Marker/the content referred to by the IPTV Content Marker item. 

7.5.2.9 GenerationTime 

This optional timestamp may store the point in time when the IPTV Content Marker item was created. 

7.5.2.10 ExpiryTime 

This optional timestamp indicates when the associated IPTV Content Marker item expires. 

7.5.3 IPTV Service Access History 
7.5.3.1 Data model 

This clause defines the data model for IPTV service access history, which can be used for: 

• User preference extraction needed by service personalization and targeting (e.g. targeted Ad, CRS, 
personalized EPG, etc.); 

• Sharing consumption history among authorized users. 

NOTE: How the user preference is extracted from the IPTV service access history is out of scope of the present 
document. 
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IPTV Service Access History 



UserlD: String 
AccessHistorylD: String 
ServiceType: Enumerated 
ReferencedContentID: String 
Rating: enumerated 
AccessStartTime: Timestamp 
AccessEndTime: Timestamp 
HistoryExpiryTime: Timestamp 



Figure 8B: IPTV service access history data model 

Figure 8B depicts the data model assumed that each IPTV user is allocated at least an IMS Public User Identity 
(i.e. IMPU) and one or multiple IPTV service access history items are associated with this identifier. 

The entries of IPTV service access history may be rendered to the user through authorization rules or be processed by 
the service provider subject to appropriate privacy and regularity mechanisms. 



7.5.3.2 



UserlD 



This attribute identifies who is the IPTV service access history item is associated. It shall always be present and has a 
string value. 

7.5.3.3 AccessHistorylD 

This attribute is used to distinguish between several IPTV service access history items of a user.It shall always be 
present and has a string value. 

7.5.3.4 ServiceType 

This attribute identifies the service type of a user's service access history, as specified in clause 1.2. It shall always be 
present and has a enumerated value. 

7.5.3.5 ReferencedContentID 

This attribute identifies the associated content accessed by the user in the context of specific ServiceType, as specified 
in clause 1. 1 . It shall always be present and has a string value. 

7.5.3.6 Rating 

This optional attribute indicates the user rating for the referened content. It has a numerated value (e.g. one-star, 
two -stars...). 

7.5.3.7 AccessStartTime 

This attribute is used to identify the time when the access to the content is started. It shall always be present and has a 
timestamp value. 
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7.5.3.8 AccessEndTime 

This attribute is used to identify the time when the access to the content is ended. It shall always be present and has a 
timestamp value. 

7.5.3.9 HistoryExpiryTime 

This optional attribute identifies the expiry time of an IPTV service access history item. It has a timestamp value. 

7.6 IPTV Content Recommendation profile 

The IPTV Content Recommendation Profile (IPTV CR Profile) data model describes the user preference on specific 
type of the content, which is needed in personalized services e.g. CRS, TAI. 



IPTV CR Profile 



Genre: string 
Keyword: string 
Creator: string 
CreationLocation: string 
CreationDate: string 



Figure 8C: Content Recommendation Profile data model 



7.6.1 Genre 



This element describes user's preference for the genre of the content. It has a string data type. 

There may be multiple occurrences of this element, with different preference value attached to each occurrence, 
indicating the relative priority with respect to other Genre elements. 

7.6.2 Keyword 

This element describes user's preference for the keyword summarizing the content. It has a string data type. 

There may be multiple occurrences of this element, with different preference value attached to each occurrence, 
indicating the relative priority with respect to other Keyword elements. 

7.6.3 Creator 

This element describes user's preference for the creator or staff who created the content, e.g. favourite director, 
actor/actress. It has a string data type. 

There may be multiple occurrences of this element, with different preference value attached to each occurrence, 
indicating the relative priority with respect to other Creator elements. 

7.6.4 CreationLocation 

This element describes user's preference for the location of the content where it was created. It has a string data type. 

There may be multiple occurrences of this element, with different preference value attached to each occurrence, 
indicating the relative priority with respect to other CreationLocation elements. 
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7.6.5 CreationDate 

This element describes user's preference for the date of the content when it was created. It has a string data type. 

There may be multiple occurrences of this element, with different preference value attached to each occurrence, 
indicating the relative priority with respect to other CreationDate elements. 

NOTE: The data model for CR profile can be extended to fulfill needs in pratical implementations. 



7.7 



IPTV Service State Data 



7.7.1 



Data model 



Figure 8D shows the data model for IPTV Service State Data. IPTV Service State Data may be held in network 
elements that constitute the IPTV solution or external applications. 



IPTV Service State Data 



ServiceStateDatald: string 
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IPTV Service State 






IPTVServiceTypeldentitier: enumerated 
IPTVContentldentifier: string 

ServiceState: enumerated 
ServiceStatelnformation: string 
Services tateExpiry Time: timestamp 
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BC Service State 
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PSC Service State 




AdInsertionPoint: stiing 


TrickPI ay Activated: boolean 


SSCRoomId: string 


PSCid: string 





































Figure 8D: IPTV Service State Data - data model 

IPTV Service State may include state information, state transition information, state history information, state transition 
history information and/or media action data/commands, e.g. current BC program ID, commercial break in BC service, 
pause during CoD playback, list of CoDs and associated status, record status of recordings, trick play status (e.g. play, 
stop, pause, or other media action data). 

IPTV Service State has the following generic attributes 

• IPTVServiceTypeldentifier. 

• IPTVContentldentifier. 

• ServiceState: state information that can be enumerated, e.g. trick play status or - commands. 
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• ServiceStatelnformation: string with additional service state information, e.g. state (transition) history. 

• ServiceStateExpiryTime, timestamp indicating the expiry time of the IPTV Service State, see clause 7.7.2. The 
default value of ServiceStateExpiryTime indicates that it expires when the associated ongoing service is 
terminated. 

Specific IPTV services may have additional attributes for their IPTV Service State, and specific implementations of 
generic IPTV Service State attributes: 

• BC Service State: TrickPlay Activated, which is "true" if trick play has been activated, see clause 8.3.5. 

• Ad Service State: AdInsertionPoint, see clause 8.14.1. 

• SSC Service State: SSCRoomID and the IPTV Service State of the IPTV services under SSC control, see 
clause 8.21. 

• PSC Service State: PSCid and the IPTV Service States of the IPTV services that the PSC is composed of, see 
clause 8.22. 

NOTE 1: The data model for SSC - and PSC Service State follows the so-called "composite design pattern". The 
individual BC and CoD Service States have their own ServiceState and ServiceStatelnformation 
attributes, which are associated in the combined SSC - or PSC Service State. 

NOTE 2: Additional attributes for other IPTV Services are not specified in TISPAN Release 3. 



7.7.2 Life cycle 



IPTV Service State Data records are kept while the associated service(s) are ongoing. Alternatively, entries may also be 
purged when the expiration time associated with a service state value (identified using ServiceStateExpiryTime) 
expires. 



8 Procedures 

8.1 IPTV addressing mechanisms 

8.1 .1 IPTV end-users identification and addressing mechanisms 

End-user identification and addressing shall be done according to what is defined in document TS 182 006 [2]. 

8.1 .2 Addressing of nodes 

As specified by TS 182 006 [2], those network nodes with reference points supporting the SIP protocol shall be 
identifiable using a valid SIP URL 



8.2 UE start-up procedure 



Figure 9 depicts the typical steps that occur at power up of the UE. Some of the steps are not new in them selves, but 
exist already in NGN. 
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UE 




NASS 




Core IMS 




SDF 




1. 


Network Attachment 


















2. IMS Registration 
























3. Attach to the IPTV Service 



4. Selection of IPTV Service 



Figure 9: UE start-up procedure 

1) Network Attachment 

In this step the UE attaches to the network. The procedures for network attachment are defined in 
ES 282 004 [3]. This step includes IP configuration, P-CSCF address discovery, etc. 

2) IMS Registration 

In this step, the UE performs regular IMS Registration as defined in TS 182 006 [2]. 

3) Service Attachment 

In this step, the UE retrieves the configuration information (server addresses and other relevant information) 
needed to retrieve the appropriate information to access the services that the user is authorized to. The user 
preferences and the capabilities of the UE can be taken into account to enable personalized service discovery. 
The UE could retrieve the service discovery information through the Push mode and Pull mode. 
Push mode: When the UE attaches to the IMS network, the SDF actively sends the service attachment 
information to the UE. 

Pull mode: After the UE attaches to the IMS network, the UE actively requests the service attachment 
information from the SDF. 

NOTE 1: The SDF discovery can be performed in several ways: through NASS attachment, by manual provisioning, 
using IFC e.g. third-party registration, etc. 

4) Service Selection 

In this step, the UE retrieves data related to specific services and makes appropriate service selection. 

NOTE 2: In case the UE needs to directly contact a network functional element, (e.g. a Service Control Function - 
SCF, or SSF), it should perform GBA authentication, for key management purposes. This procedure will 
secure further communication taking place between the UE and the IPTV Service Control Function. The 
GBA bootstrapping procedure is defined in GAA - TS 133 220 [4] and is referenced in the TISPAN NGN 
Security architecture - TS 187 003 [5]. This step is not affecting the functional behaviour of any of the 
entities involved in this start-up phase and thus, it is not displayed in this flow. 

The detailed sequence of steps 3 and 4 is described in the figures below. 
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UE 
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Figure 10: IPTV service attachment and selection in pull mode 

1) The UE makes a service attachment request. 

2) The core IMS relays the request to the appropriate entity (here, SDF). 

3) The SDF determines the proper SSF (or SSFs) according to the UE's capabilities, the user's profile and also the 
location of the UE (Personalized Service Discovery). The user profile may be retrieved from the UPSF or any 
other entity where it is stored. 

4) Configuration information that includes the SSF address(es) is (are) routed back to the UE. 

5) Core IMS relays the configuration information related to IPTV services back to UE. 

6) The UE requests the SSF to get the selection data. 

7) The SSF delivers the requested data to the UE. 

For the purpose of service configuration update, steps 4 and 5 described above can be repeated at any time after 
completion of the IPTV service attachment and selection procedure. 
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Figure 1 1 : IPTV service attachment and selection in push mode 
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1) The SDF gets the status of the UE, e.g. the S-CSCF sends a third-party REGISTER request to the SDF after 
the IMS Registration or by other method, then the SDF gets the status of the UE. 

2) The SDF determines the proper SSF (or SSFs) according to the UE's capabilities, the user's profile and also the 
location of the UE (Personalized Service Discovery). The user profile may be retrieved from the UPSF or any 
other entity where it is stored. 

3) Configuration information that includes the SSF address(es) is (are) routed back to the UE. 

4) Core IMS relays the configuration information related to IPTV services back to UE. 

5) The UE requests the SSF to get the selection data. 

6) The SSF delivers the requested data to the UE. 

8.3 Broadcast session 

The procedures described here are for streaming cases distinguished from upload/download cases (described in 
clause 8.19). 

Before the User Equipment can join a multicast channel, a session initiation procedure shall take place as described in 
clause 8.3.1. One session initiation is associated to one or more service packages. SCF does not participate in channel 
change control in order to avoid zapping delays. 

The UE retrieves necessary network parameters to handle the BC TV Service either before the session initiation 
procedure (from the SSF) or as part of the session initiation procedure (from the SCF). 

The SSF and/or the SCF acquire network parameters from management entities. 

NOTE: Alternative methods could exist, but they out of scope for this release. 

The session may be modified using the procedure described in clause 8.3.2 in the following cases: 

• The BC TV Service is modified. 

• Currently allocated resources are not sufficient and the User Equipment wishes to join a multicast channel with 
different QoS requirements (e.g. zapping from a SD to HD channel). The session modification procedure may 
take place before or after the request to change channel, in order to avoid increasing zapping delays. In the 
later case, the session modification procedure is initiated by the UE and the new channel is delivered using 
currently allocated resources until this procedure and any additional resource reservations that may be required 
are completed. 

The session can be terminated by the User Equipment using the procedures described in clause 8.3.3 or by the network. 

Interactions between the IMS and the RACS take place at different steps of the session initiation and modification and 
release. Additional resource control procedures not triggered by the IMS may also take place and are not described in 
the following clauses. 

8.3.1 Signalling flows for broadcast session initiation 
8.3.1 .1 Overview of the signalling flows for session initiation 

8.3.1 .1 .1 UE-initiated BC session initiation 

Figure 12 provides an overview of the information flows for UE-initiated BC session initiation. 
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Figure 12: UE-initiated BC session initiation 

1) The UE initiates a dialogue to the BC service which refers to the service package(s). 

2) The session initiation request is routed by the Core IMS entities up to the SCF in charge of the requested BC 

service. 

3) SignalHng procedures for the estabHshment of one or more content deHvery channels network parameters 
necessary to handle the BC service take place between the UE and the SCF (see clause 8.3.1.2). 

NOTE: In a particular protocol realization, the messages supporting step 3 may be embedded in the messages 
supporting session initiation. 

4) The SCF confirms the dialogue establishment. 

5) The P-CSCF within the Core IMS interacts with the RACS to commit all resources and to activate the service 
package(s) in transport network element at edge of network for enabling multicast joining. 

6) The P-CSCF forwards the dialogue confirmation to the UE. 

7) The UE starts joining multicast channels and receiving multicast flows. 

8.3.1 .1 .2 SCF- initiated BC session initiation 

Figure 12A provides an overview of the information flows for SCF-initiated BC session initiation. 
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Figure 12A: SCF-initiated BC session initiation 

1) The SCF sends a session initiation request to the UE via the core IMS. 

2) The Core IMS forwards the session initiation request to the UE. 

3) If the UE accepts the request, signalling procedures for the establishment of one or more content delivery 
channels network parameters necessary to handle the BC service take place between the UE and the SCF (see 
clause 8.3.1.2). 

NOTE 1: In a particular protocol realization, the messages supporting step 3 may be embedded in the messages 
supporting session initiation. 

4) The UE confirms the establishment of the dialogue with the SCF. 

5) The P-CSCF within the Core IMS interacts with the RACS to commit all resources and to activate the service 
package(s) in transport network element at edge of network for enabling multicast joining. 

6) The core IMS forwards this confirmation to the SCF. 

7) The UE starts joining multicast channels and receiving multicast flows. 

NOTE 2: SCF can initiate BC notification to UE (The procedure is described in clause 8.11.1), when UE receive 
the notification, it can initiate the BC session as figure 12. 



8.3.1.2 



Signalling flows for the establishment of the delivery channel 



8.3.1 .2.1 SCF-initiated establishment of the delivery channel 

Figure 13 shows information flows applicable when SCF initiates the establishment of content delivery channel. 
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Figure 13: Establishment of the delivery channel 

(42) The SCF initiates the establishment of one or more content delivery channels with the UE, by sending a media 
offer through the Core IMS. 

(43) The P-CSCF within the Core IMS interacts with the RACS according to the description given in the media offer. 

(44) The P-CSCF within the Core IMS forwards the media offer to the UE. 

(45) The UE provides a media answer to the Core IMS. 

(46) The P-CSCF within the Core IMS interacts with the RACS to update the configuration according to the media 
answer. 

(47) The media answer is propagated to the SCF. 



8.3.1.2.2 



UE-initiated establishment of the delivery channel 



Figure 14 provides an overview of the information flows for UE-initiated establishment of content delivery channel 
necessary to handle the BC service. 
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Figure 14: Establishment of the delivery channel 

(41) The UE initiates the establishment of one or more content delivery channels with the SCF, by sending a media 
offer through the Core IMS. 

(42) The P-CSCF within the Core IMS interacts with the RACS to reserve transport resources according to the media 
offer. 

(43) The media offer is forwarded to the SCF. 

(44) The SCF sends a media answer through the Core IMS. 

(45) Within the Core IMS, the P-CSCF interacts with the RACS to update the previous reservation (optional). 

(46) The media answer is propagated to the UE. 

8.3.2 Signalling flows for BC session modification 

The BC session modification procedure is used to modify network parameters necessary to handle the BC service in an 
existing session. 

The BC session modification procedure is initiated by the UE or the SCF. 

8.3.2.1 UE-initiated BC session modification 

Figure 15 provides an overview of the information flows for UE-initiated BC session modification. 
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Figure 15: UE-initiated BC session modification 

1) The UE initiates a session modification procedure in order to start a modification of network parameters 
necessary to handle the BC service. 

2) The session modification request is forwarded to the SCF through the Core IMS. 

3) Procedures for the negotiation of the network parameters necessary to handle the BC service take place 
between the UE and the SCF (see clause 8.3.1.2). 

NOTE: In a particular protocol realization, the messages supporting step 3 may be embedded in the messages 
supporting session modification. 

4) The SCF acknowledges the session modification. 

5) The P-CSCF within the Core IMS interacts with the RACS to commit all resources previously reserved. 

6) The P-CSCF forwards the confirmation to the UE. 

7) The UE starts joining multicast channels and receiving multicast flows. 

8.3.2.2 SCF-initiated BC session modification 

Figure 16 provides an overview of the information flows for SCF-initiated session modification. 
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Figure 16: SCF-initiated BC session modification 

1) The SCF initiates a session modification procedure in order to start a negotiation for network parameters 
necessary to handle the BC service. 

2) The session modification request is forwarded to the UE by the Core IMS. 

3) Procedures for the negotiation of the network parameters necessary to handle the BC service take place 
between the UE and the MF (see clause 8.3.1.2). 

NOTE: In a particular protocol realization, the messages supporting step 3 may be embedded in the messages 
supporting session modification. 

4) The UE confirms the modification of the session. 

5) The P-CSCF within the Core IMS interacts with the RACS to commit all resources previously reserved. 

6) The Core IMS forwards this modification to the SCF. 

7) The UE starts joining multicast channels and receiving multicast flows. 

8.3.3 Signalling flows for broadcast session release 
8.3.3.1 UE-initiated session release 

Figure 17 provides an overview of the information flows for UE-initiated session release. 
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Figure 17: UE-initiated broadcast session release 

1) The UE initiates a session termination. 

2) The P-CSCF interacts with the RACS to release all transport resources that had been reserved for this session 
and to deactivate the service package in transport network element to prevent invalid multicast joining. 

3) The Session Termination Request is routed by the Core IMS entities up to the SCF. 

4) The SCF returns a Session Termination Confirm to the Core IMS. 

5) The P-CSCF forwards the Session Termination Confirm to the UE. 

8.3.3.2 SCF-initiated session release 

Figure 18 provides an overview of the information flows for SCF-initiated session release. 
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Figure 18: SCF-initiated broadcast session release 

1) The SCF initiates a session termination. 

2) The P-CSCF interacts with the RACS to release all transport resources that had been reserved for this session 
and to deactivate the service package in transport network element to prevent invalid multicast joining. 

3) The Session Termination Request is routed by the Core IMS entities up to the UE. 

4) The UE returns a Session Termination Confirm to the Core IMS. 

5) The Core IMS forwards the Session Termination Confirm to the SCF. 

8.3.4 Signalling flow for Broadcast TV channel switching 

Figure 19 provides an example of a signalling flow for channel switching. It shows how the SCF can be informed about 
what channel is currently being watched. 
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Figure 19: Broadcast TV channel switching 
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1) The UE leaves a multicast channel and joins another multicast channel. 

2) A delay may be applied. If the user switches channel again during this delay time, the flow is restarted at 
step 1. 

3) The UE sends information about which channel is being watched. 

4) Core IMS routes the information to the SCF. 

The SCF stores channel change information in the Service Action Data. 

8.3.5 Signalling flows for transition from Broadcast TV to Broadcast TV 
with trick play 

Figure 20 provides the signalling flow for trick play of a Broadcast TV channel. In order to apply trick modes to a 
Broadcast TV session, this must be established as indicated in clause 8.3.1. 

The same session is used in the trick play session modification, in order not to change the bandwidth requirements on 
the network. At successful conclusion of these procedures the UE seamlessly transitions from viewing Broadcast TV to 
Broadcast TV with trick play. 

NOTE: As an alternative to the session modification, it is possible to initiate a separate session for trick modes 
handling, in addition to the Broadcast TV one, while keeping control of the bandwidth requirements 
between the two of them. This method is, however, out of the scope of the present document. 



£75/ 



62 



ETSI TS 182 027 V3.4.1 (2010-06) 



UE 



(1) 



Core IMS/RACS 



SCF 



MCF 



Broadcast TV session initiation 



(2) Inform current channel 



(3) Inform current chanrel 

► 



(4) Session Modification Request & Media offer 
for Content Control and Content Delivery Channel 



Reserver Resources 



(5) Session Modification Request & Media offer 
for Content Control and |Content Delivery Channel 



(6) Session Initiation Request & Media offer for 
Content Control and Content Delivery Channel 



(7) Session Initiation Response & Media answer 
for Content Control and Content Delivery Channel 



(8) Session Modification Response & Media 

answer for Content Control and Content Delivery Channel 



Reserver Commit 

(9) Session Modification Response & Media 

answer for Content Control and ConterttDDelivery Channel 



(10) Leave multicast channel 



ECF/EFF 



( 1 1) Content Control and Content Delivery Flows 



MF 



Figure 20: Signalling flow for initiating trick play of broadcast TV channel 

1) Broadcast TV session initiation. 

NOTE 1: The procedures are the same as clause 8.3.2, Overview of the signalling flows for session initiation. 
RACS and channel establishment have been removed for purpose of simplification. 

2) The UE sends information on the current channel being watched, in order for the SCF to know what channel 
should be recorded. 

3) Core IMS routes the information to the SCF. 
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4) When the UE initiates trick play mode of a Broadcast TV the UE sends a session modify request which 
includes a media offer for a content control channel and content delivery channel with the MP. If trick play 
service is not available for the UE, the session modification is not sent. 

NOTE 2: The Broadcast TV with trick play session modification is performed on the same session as the Broadcast 
TV session initiation. The existing reservation (for broadcast) needs to be modified to add a unicast flow 
that reuses the resources dedicated to the user. In the figure, RACS has been combined with Core IMS for 
the purpose of simplification. 

NOTE 3: Steps 2 and 3 are optional in a generic Broadcast TV session, but are required if trick play is activated. 
The implementation of both steps as separate messages or combined with step 4 is an implementation 

issue. 

5) After reserving resources in RACS Core IMS forwards the session modification request to the SCF. 

6) The SCF forwards the session modification request as a new session initiation to the MP along with the 
channel indication. The MP will determine if the programme currently broadcasted has trick play support.. 
Prior to replying the MP uses real time to calculate the media offset for the broadcast TV channel when 
replying with the offered media. If trick play service is not available for the UE the session modification is 
rejected and the old Broadcast TV session initiation (along with the previous reserved committed resources) is 
maintained. 

7) The MP sends the session modification response to the SCP. 

8) The SCP forwards the session modification response to the Core IMS. 

9) After committing resources in RACS Core IMS forwards the session modification response to the UE. 

10) The UE leaves the multicast channel. 

11) The UE starts playing content and receiving unicast flow. 
NOTE 4: Alternatives to the above call-flow are for further study. 

8.3.6 Signalling flows for transition from Broadcast TV with trick play to 
Broadcast TV 

The UE returns from Broadcast TV trick play to linear Broadcast TV, for example when the UE switches channels from 
a paused channel to another live Broadcast TV channels, or when the UE fast-forwarding in a unicast stream and 
catches up with the live Broadcast TV channel. 

The trigger to transition from Broadcast TV with Trick Play to Broadcast TV may be initiated by the UE, SCP or MCP. 

NOTE: The event to trigger the transition is outside of the present document. 

The UE or SCP may request a Broadcast TV session modification as described in clause 8.3.2, titled Overview of the 
signalling flows for session modification. The difference is that the Broadcast TV session modification is performed on 
the same session, in order to release unicast resources, and the SCP is responsible for releasing the resources in the 
MCP with a session termination request/response. 

The MCP may request a session termination towards SCP which in turn performs Broadcast TV session modification 
towards the UE. 

8.3.7 Signalling flows for Broadcast TV with trick play session release 

When the UE terminates the Broadcast TV with trick play the UE shall follow the same flows as clause 8.4.3. 1 . 

8.3.8 Signalling flows for Pay Per View service 

Figure 20A depicts signalling flows for PPV service, this procedure applies for IPTV users subscribing to a PPV 
program scheduled on a channel to which the user is not subscribed to. 
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Figure 20A: Signalling flows for Pay Per View session 

Prior to the PPV program session initiation, users should have subscribed a PPV program. The subscription information 
which may be saved as user profile include the user's indentity, BC service ID and BC program ID of the PPV program. 

1) UE initiates the PPV program session as the BC session initiation procedures specified in clause 8.3.1.1.1, The 
PPV specific steps here are as follows: 

i) The PPV program session initiation request includes the BC service ID and the BC program ID of the 
PPV program. 

ii) When SCF receives the request, the SCF identifies the program according to the BC service ID and BC 
program ID, and verifies based on the IPTV user profile, that the program has been PPV subscribed. 
Upon successful verification, the SCF verifies that the program is ready to start, i.e. the current time is 
greater than/equal to program start time. Then accepts the request. If not, it refuses the request. 

NOTE 1: The SCF authorizes the BC Session Initiation for that BC Service ID based on the fact that BC Program 
ID has been PPV subscribed. In the answer to the session initiation, the SCF includes information related 
to that authorized PPV program to enable the Core IMS to provision RACS with necessary parameters. 

NOTE 2: The initiation of PPV program session may be triggered by the user's action or the notification from SCF 
(e.g. SCF detects the PPV program is ready to start, and sends a notification to UE as specified in 
clause 8.11.1). 

2) The UE starts joining multicast channels and receiving multicast flows. 

3) UE or SCF initiates the PPV program session release procedure as BC session release procedures specified in 
clause 8.3.3. As part of the PPV program session release, RACS is updated by removing the BC Service. 

NOTE 3: Session release for PPV service can be initiated either by SCF or UE. SCF initiates session release when 
detects the PPV program is over. 

NOTE 4: An alternative solution using release 2 mechanisms can also be used. The SCF indicates the BC service 
ID that identifies the PPV program either at session initiation (clause 8.3.1) if the PPV programm is 
already authorised or by initiating a session modification (clause 8.3.2). If the BC session is on-going 
when the authorisation duration has elapsed, the SCF modify the session to remove the appropriate BC 
service ID from the authorised BC service list. 



8.4 



CoD session 



The procedures described here are for streaming cases distinguished from upload/download cases (described in 
clause 8.18). 
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8.4.1 Signalling Flows for CoD session initiation 

Before the User Equipment can view the content, a session initiation procedure shall take place as described in 
clause 8.4.1. 

The UE retrieves necessary network parameters to handle the CoD service before the session initiation procedure (from 
the SSF), or as part of the session initiation procedure, or after the session initiation procedure (from the MP). 

The session can be terminated by the User Equipment using the procedures described in clause 8.4.3. 1 or by the 
network clause 8.4.3.2. 

Interactions between the IMS and the RACS take place at different steps of the session initiation/modification and 
release. 

In certain cases such as in conventional content server deployments, it may be preferable that a content control channel 
and content delivery channel(s) be established separately. 



8.4.1.1 



Overall signalling flows for CoD session initiation 



8.4.1 .1 .1 UE-initiated CoD session initiation 

Figure 21 provides an overview of the information flows for UE-initiated CoD session initiation. 
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Figure 21 : UE-initiated CoD session initiation 

1) (Optionally) UE may retrieve COD offset from service action data. 

2) (Optionally) SSF may return COD offset for specified content. 

3) The UE initiates a dialogue to the CoD service. 
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4) The session initiation request is routed by the Core IMS entities up to the SCF in charge of the requested CoD 

service. 

5) The SCF performs service authorization as described in clause 5.1. If the UE is allowed to access the content, 
the SCF forwards the session initiation request to the selected MF. 

6) Signalling procedures for establishment of a content control channel and optionally (see note 2) content 
delivery channels take place between the UE and the MF (see clause 8.4.1.2.1). 

NOTE 1: In a particular protocol realization, the messages supporting step 6 may be embedded in the messages 
supporting session initiation. 

NOTE 2: The establishment of the content delivery channel in the session initiation is only optional when network 
has provided information for only content control channel setup. In this case, the content delivery channel 
is established during session modification. 

7) The MF confirms the establishment of the dialogue with the UE. 

8) (Optionally) If the session initiation does not include a COD offset, the SCF may try to retrieve a stored offset 
for this CoD service in service action data. In this case, the SCF includes this offset in the session initiation 
answer. 

9) The SCF forwards this confirmation to the Core IMS. 

10) The P-CSCF within the Core IMS interacts with the RACS to commit all resources previously reserved. This 
includes opening pinholes for exchanging content control messages and/or content delivery. 

11) The P-CSCF forwards the dialogue confirmation to the UE. 

8.4.1 .1 .2 SCF- initiated CoD session initiation 

Figure 21 A provides an overview of the information flows for SCF-initiated CoD session initiation. 
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Figure 21 A: SCF-initiated CoD session initiation 

1) (Optionally) The SCF may retrieves the COD offset if present in service action data. 

2) The SCF sends a session initiation request including the COD offset to the MF. 

3) The SCF sends a session initiation request to the UE via the core IMS. 

4) The Core IMS forwards the session initiation request to the UE. 

5) If the UE accepts the request, signalling procedures for establishment of a content control channel and 
optionally (see note 2) content delivery channels take place between the UE and the MF via the SCF (see 
clause 8.4.1.2.2). 

NOTE 1 : In a particular protocol realization, the messages supporting step 5 may be embedded in the messages 
supporting session initiation. 

NOTE 2: The establishment of the content delivery channel in the session initiation is only optional when network 
has provided information for only content control channel setup. In this case, the content delivery channel 
is established during session modification. 

6) The UE confirms the establishment of the dialogue with the SCF. 

7) The P-CSCF within the Core IMS interacts with the RACS to commit all resources previously reserved. This 
includes opening pinholes for exchanging content control messages and/or content delivery. 

8) The core IMS forwards this confirmation to the SCF. 

9) The MF confirms the establishment of the dialogue with the SCF. 

10) (Optionally) UE may retrieve COD offset from service action data. 

1 1) (Optionally) SSF may return COD offset for specified content. 
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After this point, UE may use the content control channel to request content to be streamed and the actual content will be 
then delivered/streamed over the content delivery channels. 

The content control channel will also be used to carry UE requests for controlling the streams, e.g. "pause", "fast 
forward", etc. 



8.4.1.2 



Media Channel Negotiation 



The following clauses go into details related to Content Control and/or Delivery Channel Setup steps in the session 
initiation in clause 8.4.1.1 (step 6 in clause 8.4.1.1.1 and step 5 in clause 8.4.1.1.2, respectively). 



8.4.1.2.1 



Signalling flows for the establishment of the content control and content delivery 
channels from MF 



Figure 22 shows information flows applicable when network parameters necessary to handle the CoD service are 
provided by the MF as part of the session initiation procedure. This set of information flows assume that the UE does 
not receive a description of the network parameters required from the SSF before initiating the session. 
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Figure 22: Signalling flows for the establishment of the content control and content delivery 

channels from MF 

(41) The MF initiates negotiation of a content control channel and one or more content delivery channels with the 
UE, by sending a media offer to the SCF. 

(42) The media offer is forwarded to the Core IMS. 

(43) The P-CSCF within the Core IMS interacts with the RACS to reserve transport resources for the content control 
channel and one ore more content delivery channels. 

(44) The P-CSCF within the Core IMS forwards the media offer to the UE. 

(45) The UE provides a media answer to the Core IMS. 

(46) The P-CSCF within the Core IMS interacts with the RACS to update the reservation (optional). 
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(47) The media answer for the content control channel and one or more content delivery channels is propagated to the 
SCF. 

(48) The SCF forwards the media answer to the MP. 

8.4.1 .2.2 Signalling flows for the establishment of the content control and content delivery 

channels from UE 

Figure 23 provides an overview of the information flows for UE-initiated negotiation of the network parameters 
necessary to handle the CoD service. This set of information flows assume that the UE receives a description of the 
network parameters required from the SSF before initiating the session. 
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Figure 23: Signalling flows for the establishment of the content control and content delivery 

channels from UE 

(41) The UE initiates negotiation of a content control channel and one or more content delivery channels with the 
MF, by sending a media offer to the Core IMS. 

(42) The P-CSCF within the Core IMS interacts with the RACS to reserve transport resources for the content control 
channel and one or more content delivery channels. 

(43) The media offer is forwarded to the SCF. 

(44) The SCF forwards the media offer to the MF. 

(45) The MF provides a media answer to the SCF. 

(46) The SCF forward the media answer to the Core IMS. 

(47) Within the Core IMS, the P-CSCF interacts with the RACS to update the previous reservation (optional). 

(48) The media answer for the content control channel and one or more content delivery channels is propagated to the 
UE. 

8.4.1 .2.3 Signalling flows for the establishment of the content control channel from UE 

Figure 24 provides an overview of the information flows for UE-initiated establishment of the content control channel. 
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Figure 24: Signalling flows for the establishment of the content control channel from UE 

(41) The UE initiates negotiation of a content control channel with the MF, by sending a media offer to the Core IMS. 

(42) The P-CSCF within the Core IMS interacts with the RACS to reserve transport resources for the content control 
channel. 

(43) The media offer is forwarded to the SCF. 

(44) The SCF forwards the media offer to the MF. 

(45) The MF provides a media answer to the SCF. 

(46) The SCF forward the media answer to the Core IMS. 

(47) Within the Core IMS, the P-CSCF interacts with the RACS to update the previous reservation (optional). 

(48) The media answer for the content control channel is propagated to the UE. 

8.4.2 Signalling Flows for CoD session modification 

The CoD session modification procedure is used to add, remove or modify one or more content delivery channels in an 

existing session. 

The CoD session modification procedure is initiated by the UE or the MF. 

The session modification procedure shall take place immediately after the session initiation procedure (e.g. using 
network parameters retrieved from content control messages) when no content delivery channels were set during this 
previous phase. 

In case of a session modification, the content delivery channel setup/modification procedure is always triggered by the 
entity initiating the session modification. 

8.4. 2. OA UE-initiated CoD session modification 

Figure 25 provides an overview of the information flows for UE-initiated CoD session modification. 
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Figure 25: UE-initiated CoD session modification 

1) The UE initiates a session modification procedure in order to start a negotiation for one or more content 
delivery channel(s). 

2) The session modification request is forwarded to the SCF through the Core IMS. 

3) The SCF performs service authorization as described in clause 5.1. If the UE is allowed to modify the content, 
the SCF forwards the session modification request to the MF. 

4) Procedures for establishment of a content delivery channels take place between the UE and the MF (see 
clause 8.4.2.1). 

NOTE: The messages supporting step 4 are embedded in the messages supporting session modification. 

5) The MF confirms the modification of the session. 

6) The SCF forwards this modification to the Core IMS. 

7) The P-CSCF within the Core IMS interacts with the RACS to commit all resources previously reserved. This 
includes opening pinholes for content delivery. 

8) The P-CSCF forwards the confirmation to the UE. 

After this point, UE may request content to be delivered over the content control channel and the actual content will be 
then delivered over the content delivery channels. 

The content control channel will also be used to carry UE requests for controlling the streams over the content delivery 
channels, e.g. "pause", "fast forward", etc. 
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8.4. 2. OB MF-initiated CoD session modification 

Figure 26 provides an overview of the information flows for MF-initiated CoD session modification. 
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Figure 26: MF-initiated CoD session modification 

1) The MF initiates a session modification procedure in order to start a negotiation for one or more content 
delivery channel(s). 

2) The SCF performs service authorization as described in clause 5.1. The SCF forwards the session modification 
request to the MF. 

3) The session modification request is forwarded to the UE by the Core IMS. 

4) Procedures for establishment of a content delivery channels take place between the UE and the MF (see 
clause 8.4.2.2). 

NOTE: The messages supporting step 4 are embedded in the messages supporting session modification. 

5) The UE confirms the modification of the session. 

6) The P-CSCF within the Core IMS interacts with the RACS to commit all resources previously reserved. This 
includes opening pinholes for content delivery. 

7) The Core IMS forwards this modification to the SCF. 

8) The SCF forwards the confirmation to the MF. 

After this point, UE may send a request over the content control channel to stream content and the actual content will be 
then delivered over the content delivery channels. 
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The content control channel will also be used to carry UE requests for controlling the content streams e.g. "pause", "fast 
forward", etc. 

8.4.2.1 Signalling flows for the establishment/modification of the content delivery 

channel from UE 

Figure 27 provides an overview of the information flows for UE-initiated establishment or modification of the content 
delivery channel. 
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Figure 27: Signalling flows for the establishment/modification of 
the content delivery channel from UE 

(41) The UE initiates negotiation of one or more content delivery channel with the MF, by sending a media offer to 
the Core IMS. 

(42) The P-CSCF within the Core IMS interacts with the RACS to reserve transport resources for the content delivery 
channels. 

(43) The media offer is forwarded to the SCF. 

(44) The SCF forwards the media offer to the MF. 

(45) The MF provides a media answer to the SCF. 

(46) The SCF forward the media answer to the Core IMS. 

(47) Within the Core IMS, the P-CSCF interacts with the RACS to update the previous reservation (optional). 

(48) The media answer for the content delivery channels is propagated to the UE. 

8.4.2.2 Signalling flows for the modification of the content delivery channels from MF 

Figure 28 provides an overview of the information flows for MF-initiated modification of the content delivery channel. 
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Figure 28: Signalling flows for the modification of the content delivery channels from IVIF 

(41) The MF initiates negotiation of one or more content delivery channels with the UE, by sending a media offer to 
the SCF. 

(42) The media offer is forwarded to the Core IMS. 

(43) The P-CSCF within the Core IMS interacts with the RACS to reserve transport resources for the content delivery 
channels. 

(44) The P-CSCF within the Core IMS forwards the media offer to the UE. 

(45) The UE provides a media answer to the Core IMS. 

(46) The P-CSCF within the Core IMS interacts with the RACS to update the reservation (optional). 

(47) The media answer for the content delivery channels is propagated to the SCF. 

(48) The SCF forwards the media answer to the MF. 

8.4.3 Signalling Flows for CoD session release 
8.4.3.1 UE-initiated session release 

Figure 29 provides an overview of the information flows for UE-initiated session release. 
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Figure 29: UE-initiated session release 

1) The UE initiate a session termination. 

2) The P-CSCF interacts with the RACS to release all transport resources that had been reserved for this session. 

3) The Session Termination Request is routed by the Core IMS entities up to the SCF. 

4) The SCF forwards the Session Termination Request to the appropriate Media Function. 

5) The Media Function (i.e. the MCF) release all resources associated with the session and returns a Session 
Termination Confirm. 

6) The SCF forwards the Session Termination Confirm to the Core IMS. 

7) The P-CSCF forwards the Session Termination Confirm to the UE. 

8.4.3.2 SCF-initiated session release 

Figure 30 provides an overview of the information flows for SCF-initiated session release. 
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Figure 30: SCF-initiated session release 

1) The SCF initiates a session termination towards the MF. 

2) The Media Function (i.e. the MCF) releases all resources associated with the session and returns a Session 
Termination Confirm. 

3) The SCF initiates a session termination towards the UE. 

4) The P-CSCF interacts with the RACS to release all transport resources that had been reserved for this session. 

5) The Session Termination Request is routed by the Core IMS entities up to the UE. 

6) The UE returns a Session Termination Confirm to the Core IMS. 

7) The Core IMS forwards the Session Termination Confirm to the SCF. 

8.4.3.3 MF-initiated session release 

Figure 3 1 provides an overview of the information flows for MF-initiated session release. 



£75/ 



77 



ETSI TS 182 027 V3.4.1 (2010-06) 



UE 



RAGS 



Core IMS 



SCF 



MF 



(2) Session Termina|tion 
Request 



(3) Resources release 



(4) Session Termination Request 



(5) Session Termir ation Confirm 



(6) Session Termina|tion 
Confirm 



(1) Session Terminaton 



Request 



(7)Session Term inatipn 
Confirm 



Figure 31 : MF-initiated session release 

1) The MF initiates a session termination towards the SCF. 

2) The SCF forwards the session termination request to the Core IMS. 

3) The P-CSCF interacts with the RACS to release all transport resources that had been reserved for this session. 

4) The Session Termination Request is routed by the Core IMS entities up to the UE. 

5) The UE returns a Session Termination Confirm to the Core IMS. 

6) The Core IMS forwards the Session Termination Confirm to the SCF. 

7) The SCF forwards the Session Termination Confirm to the MF that releases all resources associated with the 
session. 

8.4.4 Signalling Flows for CoD session transfer 

The CoD session transfer is used to transfer an on-going CoD session from one terminal called transferor UE to another 
one called transferee UE. 

The transferor UE and the transferee UE must be served by different or the same SCF. 

The session transfer could be handled directly between both terminals or can be managed by the transferee SCF. In the 
latter case, the transferor SCF will initiate a CoD session with the transferee UE at session transfer request from the 
transferor UE. 

NOTE: 3GPP Release 9 specifications are limited to UE centric push mode for session transfer, i.e. only the case 
in clause 8.4.4.1 is addressed by 3GPP in release 9. For reference, the related 3GPP specifications are 
TS 123 237 [17] and TS 124 237 [18]. 



8.4.4.1 



Terminal centric session transfer pushed from transferor UE to transferee UE 



Figure 31 A provides an overview of the information flows for direct CoD session transfer between the transferor UE 
(UEl) and the transferee UE (UE2). For clarity purpose, core-IMS is not indicated in the figure but all messages go 
through it. 

In this scenario the transferor UE discovers the devices to which a potential transfer can be initiated. The transferor UE 
selects a devices and initiates the procedure. 
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Figure 31 A: Terminal centric session transfer pushed from transferor UE to transferee UE 

1) UEl has initiated a dialogue to the CoD service as defined in clause 8.4.1. A session is on going with the MFl. 

2) The user decides to transfer the session to another device. UEl performs device discovery as defined in 3GPP 
TS 123 237 [17], and TS 124 237 [18] to discover the devices that it can transfer the session to. 

3) The UEl may send an offset notification to the SCF. If the SCF has not received an offset notification from 
UEl it uses CoD Service Action Data requested by the SCF procedure to acquire an offset. 
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4) UEl sends a Session Transfer Request to the SCF via the core-IMS containing Session transfer identifier- STI 
(identity of the session to be transferred). The SCF obtains the CoD content-id, and perform service 
authorisation and checks that the user is authorised to perform session transfer. The SCF also obtains the UE2 
identity and the target user identity from the incoming request. 

To allow UE2 to acquire the content id used to set up the initial session, UEl shall include the content id in the 
session transfer request. 

5) The Session Transfer Request, including the offset, is forwarded from the SCF to the UE2 via the Core-IMS. 

6) UE2 receives an invitation to initiate a CoD session for the content indicated by the content-id. It 
acknowledges the Request by sending a Session Transfer Response to the SCF via the Core-IMS. 

7) The SCF forwards the Session Transfer Response to the UEl via the Core-IMS. 

8) The UE2 informs the UEl that it initiates the CoD session initiation by sending a Session Transfer Start 
Notification to the UEl via the core-IMS. 

NOTE 1: This message can optionally go through the SCF. 

9) CoD session initiation between the UE2 and MF2 via core-IMS is done as defined in clause 8.4.1.1.1. 

10) The UE2 informs the UEl that CoD session initiation is complete by sending a Session Transfer Complete 
Notification to the UEl. 

NOTE 2: This message can optionally go through the SCF. 

1 1) The UEl terminates the CoD session with the MFl as defined in clause 8.4.3.1. 

8.4.4.2 Network centric session Transfer pushed from transferor UE to transferee UE 

Figure 3 IB provides an overview of the information flows for CoD session transfer between the transferror UE (UEl) 
and the transferee UE (UE2) managed by the transferor SCF. For clarity purpose, core-IMS is not indicated in the figure 
but all messages go through it. 
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Figure 31 B: Network centric session Transfer pushied from transferor UE to transferee UE 

1) UEl has initiated a dialogue to the CoD service as defined in clause 8.4.1. A session is on going with the MFl. 

The user decides to transfer the session to the another device. UEl performs device discovery as defined by 

TS 123 237 [17], and TS 124 237 [18]. 

2) The UEl may send an offset notification to the SCF. If the SCF has not received an offset notification from 
UEl it uses CoD Service Action Data requested by the SCF procedure to acquire an offset. 

3) UEl sends a Session Transfer Request to the SCF via the Core- containing the Session Tranfer Identfier-STI 
(the identity of the session to be transferred) and if necessary the UE2 ID (e.g. if the user ID corresponds to 
multiple UEs). The SCF obtains the CoD content-id, and performs service authorisation and also checks that 
the user is authorised to perform session transfer. The SCF also obtains the UE2 identity and the target user 
identity from the incoming request. 

To allow UE2 to acquire the content id used to set up the initial session, UEl shall include the content id in the 
session transfer request. 

4) The SCF replies by a Session Transfer Response to the UEl. 
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5) The SCF informs the UEl that it initiates the CoD session initiation by sending a Session Transfer Start 
Notification to the UEl via the core-IMS. 

6) SCF-initiated CoD session initiation between the UE2 and MF2 is done by the SCF as defined in 
clause 8.4.1.1.2. 

7) The SCF informs the UEl that CoD session initiation is complete by sending a Session Transfer Complete 
Notification to the UEl. 

8) The SCF terminates the CoD session between the UEl and the MFl as defined in clause 8.4.3.2. 

8.4.4.3 Session Replication pushed from transferor UE to transferee UE 

This scenario is identical to the session transfer in clause 8.4.4.1 with the exception that the last step of terminating the 
session towards the transferor UE is not carried out. Hence, the transferor UE maintains his session as well. 

At the end of the procedure both the transferor UE and the transferee UE have independent sessions watching same 
content from the same or a different MF. 

8.4.4.4 Session Transfer pulled by the transferee UE 

Figure 31C provides an overview of the information flows for direct CoD session transfer between the transferor UE 
(UEl) and the transferee UE (UE2). 

In this scenario the transferee UE discovers the devices and the active sessions on these devices that he can transfer to 
his own device. 
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Figure 31 C: Session Transfer pulled by the transferee UE 

1) UEl has initiated a dialogue to the CoD service as defined in clause 8.4.1.1.1. A session is on going with the 
MFl. 

2) The user decides to go to his device UE2, to transfer an ongoing CoD session from device UEl. The user on 
UE2 performs device discovery and requests from SCF the active sessions on these devices, as defined by 
TS 123 237 [17], and TS 124 237 [18]. 
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3) The user on UE2 sends a Session initiation to the SCF via the core-IMS, to transfer the session from device 
UEl. The UE includes the Session Transfer Identfier-STI (identity of the session to be transferred) in his 
request. The SCF obtains the CoD content-id, from the incoming session initiation request (acquired by UE2 in 
step2), and performs service authorisation and checks that the user is authorised to perform session transfer. 
UEl may send an offset notification to SCF. If the SCF has not received an offset notification from UEl it 
uses network initated content marker procedure to acquire an offset. 

4) UE2 informs the UEl that it initiates the CoD session initiation by sending a Session Transfer Start 
Notification to the UEl via the core-IMS. 

NOTE 1 : This message can optionally go through the SCF. 

5) The UE2 informs the UEl that CoD session initiation is complete by sending a Session Transfer Complete 
Notification to the UEl. 

NOTE 2: This message can optionally go through the SCF. 

6) The UEl terminates the CoD session with the MFl as defined in clause 8.4.3.1. 



8.4.4.5 



Session Replication Between transferor to transferee in a pull mode transfer 



This scenario is identical to the session transfer in clause 8.4.4.4 with the exception that the last step of terminating the 
session towards the transferor UE is not carried out. Hence, the transferor UE maintains his session as well. 

At the end of the procedure both the transferor UE and the transferee UE have independent sessions watching same 
content from the same or a different MF. 

8.4.5 Signalling flows for CoD service action data update/Requests 

CoD service action data may be updated by UE as described in clause 8.4.5. 1 and generically may be updated by MF as 
described in clause 8.4.5.2. Furthermore, CoD service action data requests may be initiated by the SCF as described in 
clause 8.4.5.3. 

8.4.5.1 CoD service action data updated by UE 

The UE use the procedure described in figure 3 ID to save a current CoD SAD. 

This procedure may occur at any time. The most common use case is the stop CoD viewing request. 
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Figure 31 D: CoD service action data updated by UE 

1) The UE sends a CoD SAD update request to save the current position of the content. This request may also 
include a indicator to inform the SCF of the reason for the CoD SAD update. 

2) The IMS core forwards this request to the SCF. 
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3) The SCF store this offset as service action data for this user. 

4) The SCF confirms the CoD SAD update. 

5) The IMS core forwards the response to the UE. 

8.4.5.2 CoD service action data updated by MF 

The procedure described in figure 3 IE is used to save a CoD service action data by MF. 

This CoD SAD may need to be updated for example when a user pauses a streaming, terminates the session or if the MF 
detects that the UE becomes unexpectedly offline. 
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IMS 



SCF 



(1) Cod session initialization 



MF 



(2) The MF detects that the UE 

pauses the streams, ends the 

session or gets offline 

unexpectedly, etc 

MF decides to report this change 



(3) CoD SAD update request 



(4) CoD SAD 
update request 



(6) CoD SAD update 
response 



(5) Save SAD 



(7) CoD SAD update response 



Figure 31 E: CoD service action data updated by IVIF 

1) CoD session initiation is performed as described in clause 8.4.1. 

2) MF detects a pause, end of session or that the UE becomes offline unexpectedly. The MF may decides to send 
changes of SAD to SCF. 

3) MF sends a CoD SAD update request to save the current CoD SAD. This request may also include a indicator 
to inform the SCF of the reason for the CoD SAD update. 

4) The IMS core forwards this request to the SCF. 

5) The SCF updates the CoD SAD. 

6) The SCF confirms the CoD SAD update. 

7) The IMS core forwards the response to the MF. 
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8.4.5.3 CoD Service Action Data requested by tine SCF 

This procedure allows the SCF to acquire the current offset in a streamed content during an ongoing session in case 
such information is not available and required. 

Figure 3 IF provides an overview of the information flow for a CoD SAD request by the SCF to acquire the offset. This 
procedure can occur at any time during IPTV services (CoD/N-PVR/etc). 



SCF 



(1) IPTV SAD Request 



r 5) IPTV SAD Response 



Core IMS 



MP 



(2) IPTV SAD Request 



(3) MF fetches the 
information 



( A) IPTV SAD Response 



Figure 31 F: SCF SAD Request Procedure 

1) The SCF sends a SAD request to the MF, via the IMS core, to request the offset during an ongoing IPTV 
service. 

2) The IMS core forwards this request to the appropriate MF for the IPTV service. 

3) The MF acquires the requested information. 

4) The MF returns to core IMS the requested information in a SAD response. 

5) The IMS core forwards the response to the SCF. 

8.4.6 Signalling flows for generating playlist by SCF and sending playlist 
information from SCF to MF during CoD session initiation 

Figure 31G provides an overview of the information flows for playlist generation by SCF and sending playlist 
information from SCF to MF when UE initiated CoD session. 



£75/ 



86 



ETSI TS 182 027 V3.4.1 (2010-06) 




Core IMS 



SCF 



MF 



(2) Session Initiation 



Request 



(3) playlist generation/ 
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6) Steps 6-11 of 8.4.1.1.1 



Figure 31 G: Playlist communication during CoD session initiation 

1) The UE initiates a dialogue to the CoD service as defined in clause 8.4.1.1.1, step 3. 

2) The session initiation request is routed by the Core IMS entities up to the SCF in charge of the requested CoD 
service as defined in clause 8.4.1.1.1, step 4. 

3) The SCF performs service authorization as described in clause 5.1. If the UE is allowed to access the service, 
the SCF generates playlist information or fetches a pre-configured playlist from a repository, based on the 
content ID carried in the session initiation request. Other information (e.g. the User ID, etc.) may also be used 
to generate the playlist. The playlist contains the list of content ID to be played and optionally content duration 
and restricted trick-play indication for each content. The data model for playlist is defined in clause 8.4.6.1. 

4) The SCF selects an appropriate MF and forwards the session initiation request including playlist information 
to the selected MF. 

NOTE 1 : The above procedure supports only content delivery from one single MF. 

5) The MF interprets playlist information and prepares for content delivery. 

6) Content Control and or Content Delivery Channel Setup procedures and finalization of the CoD Session 
initiation procedure follow clause 8.4.1.1.1, steps 6-11. 

NOTE 2: During this signalling, the UE might learn that a playlist was generated and act accordingly. Depending 
on the service type, the UE might already have learned the playlist in advance of service invocation. 



8.4.6.1 



IPTV Data Model for playlist 



8.4.6.1.1 



General 



This clause defines the data model for playlist for IPTV CoD/N-PVR/Ad content delivery, which can be used for 
content delivery. 
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IPTV playlist 



l...n 



IPTV Content 



ContentID: String 
Duration: String 
Begin Time: String 
Restricted trick play: boolean 



Figure 31 H: IPTV playlist 

8.4.6.1.2 ContentD 

This attribute identifies the associated content. 

• In case of CoD, it shall be set to the "CoDId" (see clause 7.4.1). 

• In case of N-PVR, it shall be set to the "N-PVRContentId" (see clause 7.4. 1). 

• In case of Ad, it shall contain the ad content id (see clause 8.14.1). 

8.4.6.1.3 Duration 

This optional attribute may be used to identify the duration of IPTV content. 

8.4.6.1.4 Begin Time 

This optional attribute may be used to identify the starting point of IPTV content. 

8.4.6.1.5 Restricted trick play 

This optional attribute may be used to identify whether trick play control for IPTV content is allowed or not. 

8.4.7 Signalling flows for generating playlist by SCF and sending playlist 
information from SCF to MP during an existing CoD session 

Figure 311 provides an overview of the information flows for playlist generation by SCF and sending playlist 
information from SCF to MF during an existing CoD session. This playlist may be a new playlist or an update. 
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(3) playlist information 



(4) playlist interpretation 



Figure 311: Playlist communication during an existing CoD session 

1) A CoD session has been successfully established as described in clause 8.4.1.1 

2) Due to detecting an event, the SCF may choose to generate or update playlist information for the ongoing CoD 
session. The playlist contains the list of content ID to be played and optionally content duration and restricted 
trick-play indication for each content. 

3) The SCF passes the playlist information to the MF. 

4) The MF interprets the playlist information and acts accordingly. This may have immediate impact on the 
ongoing media channel. 

NOTE: A new or updated playlist might make a modification of the session necessary. 

8.4.8 Content switch procedure within a CoD playlist 

Figure 31J provides an overview of the information flows for content switch within a CoD playlist. 
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(l).Playlist communication during CoD session initiation(in Clause 8.4.6) 



(2). Request for content switch 



(3). Content switch response 



(4). New content delivery 



Figure 31J: Content switch within a CoD playlist 

1) The UE initiates a dialogue to the CoD service as defined in clause 8.4.6. In addition,the playlist which is 
generated by the SCF as defined in clause 8.4.6 may be forwarded to the UE by the MF for user to choose the 
subsequent content. 

2) The UE sends the content switch request related to the selected content within the playlist. The similar 
mechanism defined in TS 126 234 [i.20] clause 5.5.4.2 may be used here. 

3) The MF checks that the selected content is referred in the playlist, and confirms the request. 

4) The MF starts to deliver the new content, reusing the established media channel in case of the numbers of 
channels and QoS requirements are the same as the previous channel. 

NOTE: Session modifications may be needed if QoS requirements of the new content is not the same as the 
previous one. 

8.5 PVR service procedures 
8.5.00 PVR use for non-BC services 

Although the procedures in the following clauses focus on PVR-recording of BC services (clause 8.3), they maybe 
applicable to the recording of other IPTV services. Depending on the service, specific requirements on e.g. user 
subscription and profile may apply. Examples such as Content on Demand (clause 8.4) and Personal Service 
Composition (clause 8.22), among others, can be accommodated by using the appropriate IPTV Content Identifier and 
initiating the appropriate type of IPTV session. Details on PVR usage for each of these services are not specified in the 
present document. 

8.5.0A Signalling Flows for PVR Using Impulsive Request 

Figure 32 depicts the typical steps that occur when the UE makes an impulsive request for a PVR service. 
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Figure 32: PVR capture using impulsive request 

Specifics of interaction with RACS have been removed for purpose of simplification. It will follow the same procedures 
as outlined in the BroadcastTV and COD flows in clauses 8.3 and 8.4. 

1) UE initiates Broadcast TV session following procedures specified in clause 8.3.1.1.1. 

2) The user (on UE) makes a request to the SCF through the core IMS to capture the currently watched live 
content. During this step, the UE identifies to the SCF the content to be recorded using the IPTV content 
identifier, see Annex 1. 1, and possibly other parameters (e.g. time channel delimitation code, beginning date, 
end date, duration, etc.). The UE also indicates the type of recording (N-PVR or C-PVR) and the target UE. 
The target UE identifies either the UE that is asked to record the content in case of C-PVR or the UE where the 
content will be downloaded, if required, in case of N-PVR. 

The SCF may override the PVR request from the target UE (N-PVR or C-PVR) based on the service provider's specific 
service policy in SCF and the PVR subscription. 

In case of N-PVR, The SCF may check the N-PVR max-duration parameter to decide whether to allow the user to 
capture the selected live content. Instead of specifying a time limit, the UE may specify the current ProgrammelD 
indicating that the current Broadcast programme needs to be captured. The SCF answers with an N-PVR content 
capture response indicating to the user if capture of the content is allowed or not. 

In case of C-PVR or N-PVR with download, the SCF will check whether the target UE is authorized to record or 
receive the selected live content, and in the case of one UE-A scheduling C-PVR Service Capture Request for another 
UE-B, SCF further checks that UE-B has C-PVR terminal capabilities and UE-A is authorized by UE-B to make 
C-PVR Capture Requests on behalf of UE-B. Optionally, the SCF notifies the target UE of the storage requirements for 
the actual recording. For example, SCF calculates the required storage space according to the time duration and the 
content metadata information, the target UE checks the local storage capabilities and reserves corresponding space for 
the recording. 
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3 A) In case of N-PVR, the SCF records the PVR/BC bookmark information as part of the IPTV service action data 
and then follows relevant procedures to initiate the recording of the content by the MF 

3B) In case of C-P VR, the SCF records the PVR/BC bookmark information as part of the IPTV service action data 
and then follows procedures in clause 8.5.2.2 to initiate the recording of the content by the specified client 
device. 

4) The UE initiates Broadcast session termination procedures as defined in clause 8.3.3.1.1. Depending on the 
usage model, the UE initiates the Broadcast session termination procedure immediately after issuing the PVR 
capture request or it may do it at later point. The former would be the typically be the case of "Park and Pickup 
TV". 

NOTE: In case of N-PVR, The SCF may check if the N-PVR content is Time-shifted content, or was already 
pre-recorded for another user. Then the MF does not need to record the same content according to the 
information from SCF to avoid that the same content is recorded repeatedly. 

8. 5. OB Signalling flows for the PVR off-line capture request 

Figure 33 depicts the typical steps that occur when the UE makes an offline request for a PVR service. 





(1). PVR contei it capture request 



CORE IMS 



(1). PVR contei it capture response 
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(1). PVR content j;apture response 




(2 A ) Store N-PVR/BC Information and 
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(2 B) Store C-PVR/BC Information and initiate the recording of the content 



Figure 33: PVR Capture procedures using offline request 

1) The user (on UE) makes a request to the SCF through the core-IMS to capture a particular live content. During 
this step, the UE identifies to the SCF the content to be recorded using the IPTV content identifier, see 
clause I.l, and possibly other parameters (e.g. time channel delimitation code, beginning_date, end_date, 
duration, etc.). The UE also indicates the type of recording (N-PVR or C-PVR) and the target UE. The target 
UE identifies either the UE that is asked to record the content in case of C-PVR or the UE where the content 
will be downloaded, if required, in case of N-PVR. 

The SCF may override the PVR request from the target UE (N-PVR or C-PVR) based on the service provider's specific 
service policy in SCF and the PVR subscription. 

The SCF may check the N-PVR max-duration parameter to decide whether to allow the user to capture the selected live 
content. 

NOTE 1: The content capture request may go to the SSF instead of the SCF. This implies that the SSF needs to 

communicate with the SCF. A reference point for direct communication between the SSF and SCF is out 
of scope for this release. 
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In case of C-PVR or N-PVR with download, the SCF will check whether the target UE is authorized to record or 
receive the selected live content, and in the case of one UE-A scheduling C-PVR Service Capture Request for another 
UE-B, SCF further checks that UE-B has C-PVR terminal capabilities and UE-A is authorized by UE-B to make 
C-PVR Capture Requests on behalf of UE-B. Optionally, the SCF notifies the target UE of the storage requirements for 
the actual recording. For example, SCF calculates the required storage space according to the time duration and the 
content metadata information, the target UE checks the local storage capabilities and reserves corresponding space for 
the recording. 

2) The SCF stores the PVR/BC information. In case of N-PVR, as described in step 2A), the SCF follows 

relevant procedures to initiate the recording of the content by the MF. In case of C-PVR, as described in step 
2B), the SCF follows procedures in clause 8.5.2.2 to initiate the recording of the content by the specified client 
device. 

NOTE 2: In case of N-PVR, The SCF may check if the N-PVR content is Time-shifted content, or was already 
pre-recorded for another user. Then the MF does not need to record the same content according to the 
information from SCF to avoid that the same content is recorded repeatedly. 



8.5.1 Network PVR service procedures 



Network PVR (N-PVR) service is used by the UE to ask for a capture of live content by the network and to access it 
later on. 

The N-PVR service procedures comprise two major steps: 

Step 1: Request for N-PVR Service Capture Request 

The UE sends an N-PVR content capture request to the SCF. This request can be: 



• 



an impulsive request: in this case, a BC service is already activated. The UE asks the SCF to record the live 
content currently being watched. This may be a request to record current Broadcast Programme or a sequence 
of programmes from a given position in time (BC bookmark). This is as discussed in clause 8.5.1.1.1. 

• an off-line request: the UE asks the SCF to record a particular live content unrelated to any active BC session, 
may be a request to record current Broadcast Programme or a sequence of programmes This is as discussed in 
clause 8.5.1.1.2. 

Step 2: Request for N-PVR service 

Once recorded, the user can make a request for previously recorded N-PVR request. The N-PVR content can be 
resumed on the same UE or different UE belonging to user from start or from the point at which the content recording 
was requested. The N-PVR content may have also been downloaded to the UE making local watching of the content 
possible. 

NOTE: The case when an N-PVR service capture is done as an impulsive request and is requested later from the 
same or another UE from the point at which the content recording was requested can be viewed as a case 
of "Park and Pickup TV" as described in clause 3.1. In this case, the currently active Broadcast TV 
programme or channel that was scheduled for an impulsive N-PVR capture request can be requested at a 
later point on the same or different UE from the previously paused/parked point. 

8.5.1 .1 Signalling Flows for Network-PVR Service Capture Request 

This can be handled as an off-line request or as an impulsive request. 

8.5.1 .1 .1 Signalling Flows for Network-PVR Using Impulsive Request 

Refer to clause 8.5.0A. 

8.5.1 .1 .2 Signalling flows for the Network-PVR off-line capture request 

Refer to clause 8.5.0B. 



£75/ 



93 



ETSI TS 182 027 V3.4.1 (2010-06) 



8.5.1 .2 Signalling flows for Network-PVR content session 

Figure 34 depicts the typical steps that occur when the UE makes a request to retrieve/resume previously recorded 
N-PVR content. 

NOTE: If the N-PVR content has been previously downloaded to the UE, it can watch it locally without using the 
following procedures. 
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Figure 34: Signalling flows for Network-PVR content session 

The SSF presents the UE with listing of available N-PVR Broadcast TV content captured via impulsive or 
offline capture requests, from which the user can select. In addition the "BC bookmark" information could be 
presented by the SSF else the UE can make a separate request to retrieve it from the SCF as specified in 
step (3). 

The UE initiates an N-PVR session. The N-PVR session is equivalent to the CoD session. Therefore 
procedures defined in clause 8.4.1.1.1 apply. 

The UE may request to the SCF through the core-IMS BC bookmark information pertaining to the Broadcast 
TV programme(s) that was previously requested to be recorded. 



NOTE 1: Instead of having the UE retrieve the BC bookmark information as in Step (1) or (3), it may be possible 

for SCF to directly send the BC bookmark information from IPTV service action data to the MCF. Details 
of the procedures are out of scope for this release. 

NOTE 2: This is a logical step. For efficiency purposes it may be combined with step (2). 

4) The UE makes a request to play the content from specified bookmarked location. 

5) This includes procedures for trick play control of the resumed BroadcastTV stream. 
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6) When the UE wishes to modify to terminate the resumed BC programme, it follows session termination 
procedures as specified in clauses 8.4.2.1 and 8.4.3.1. 

8.5.2 Client PVR service procedures 

Client PVR (C-PVR) service is used by the UE to ask for a capture of live content locally or by the remote client device 
and to access the recorded content later on. 

NOTE 1 : In case of local capture requests that do not need network IPTV management or authorization, the 
recording can be handled locally on the client without SCF involvement. The procedures for local 
recording on client without SCF involvement is outside scope of specification. 

The C-PVR service procedures comprise three major steps: 

Step 1 : Initiate C-PVR Service Capture Request. 

The UE sends a C-PVR content capture request to the SCF. This request can be an impulsive request or an off-line 
request. Impulsive request and off-line request are the same with the definitions in clause 8.5. This step is used for SCF 
to perform C-PVR service authorization, or where one UE schedules the C-PVR task for a future time or for another 
UE. 

NOTE 2: If further mechanisms are required to protect the digital rights of the content, the system could use DRM 
to prohibit unauthorized access to the content. 

Step 2: Request for initiation of the C-PVR recording session. 

When the event for the C-PVR recording have been reached (e.g. beginning time of a TV program), the SCF initiates a 
request to UE to trigger the initiation of the C-PVR recording session and record the content. 

NOTE 3: in case the UE makes an impulsive request for a C-PVR service, the existing BC session may be reused, 
thus the step 2 is optional. 

NOTE 4: The SCF may not be required to trigger the C-PVR recording, e.g. in the case where the UE directly 

initiates a recording session by a timer, external trigger, or by user control. These procedures are out of 
scope of the current specification 

Step 3: Access the recorded content. 

Once recorded. The C-PVR content can be resumed on the UE which stored the content from the point at which the 
content recording was requested. 

NOTE 5: Since the content is stored on the UE, it will not be required to have any further interaction between the 
UE and any other network entities to either access or play recorded content in this step. 

8.5.2.1 Signalling Flows for Client-PVR Service Capture Request 

8.5.2.1 .1 Signalling Flows for Client-PVR Using Impulsive Request 

Refer to clause 8.5.0A. 

8.5.2.1 .2 Signalling flows for the Client-PVR off-line capture request 

Refer to clause 8.5.0B. 

8.5.2.2 Signalling flows for Client-PVR recording session 

Figure 34A depicts the typical steps when the SCF makes a request to initiate the recording of the content. For the 
scenario when the UE makes an impulsive request for a C-PVR service, the existing BC session may be reused if one 
exists instead of the following procedures. 
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Figure 34A: Signalling flows for Client-PVR recording session 

1) The SCF detects the event that triggers the C-PVR service, e.g. when the BC program is ready to be recorded. 
The SCF initiates a notification request to the UE designated by the C-PVR content capture request to record 
the content, and the notification request carries parameters to identify the content to be recorded (e.g. BC 
service id and or current BC Programme ID, time channel delimitation code, beginning date, end date, 
duration, etc.) and indicates that the content should be recorded. 

NOTE: The notification request procedures are the same as sending notification using signalling path specified in 
clause 8.11.1.1. 

2) UE initiates BC session initiation procedures as specified in clause 8.3.1.1.1, and after the content delivery 
channel setup, the UE joins multicast channels and receives multicast flows. 

3) The UE records the multicast flows. 

4) When the end time of the recording is reached, the UE or SCF initiates BC session release procedures as 
specified in clause 8.3.3. 



8.5.3 PVR content update procedures 
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Figure 34B: PVR content update procedure 
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1) The UE sends a PVR content update request to change information on existing PVR content capture request or 
existing PVR content. It includes the PVR content ID and the related change request: 

Cancellation of a content capture request. 

Modification of recording parameters (e.g. time range). 

Deletion of a recorded content. 

2) The SCF checks if the request is valid (e.g. the PVR Id exists, the time range modification is possible, etc.) and 
applies the PVR content update. 

NOTE: In case of N-PVR content deletion request, the SCF deletes the related entry in the PVR table for that 
user. It can also take appropriate action to delete the related content in case the content is recorded only 
for that user. 

3) The SCF sends a PVR Content Update response to the UE via the core IMS. In case of C-PVR, the UE applies 
the PVR content update (e.g. it deletes the related content). 



8.6 Time Shift service procedures 



The Time Shift service is used by the UE to view a programme that has already occurred or started. It is necessary for 
the IPTV operator to store a programme in order for this service to be available. Note that unlike N-PVR it is not 
necessary for a UE to indicate that a programme shall be recorded but it is not always the case that a programme is 
Time Shift enabled. The time to live for Time Shifted enabled programmes have a different expiration time compared to 
N-PVR (example 1 week compared to possible 6 months for N-PVR). For a programme that has not finished it is 
possible that the UE catches up with the broadcasted programme sent in real time. 

The user selects timeshift content from the information provided by the SSF; just as any other CoD content. 
Consequently initiation and termination of time-shift sessions are exactly the same as for CoD, as described in 
clauses 8.4.1 and 8.4.3 respectively. 

Modification of the session is also the same as for the CoD service, as described in clause 8.4.2, except for the special 
case when the timeshift session catches up with real time, at which time the session may be modified to switch over to 
multicast. In this case the same flows as for trickplay TV will be used. 

8.7 Preview procedures 

8.7.1 Preview procedures for BC service 

The preview content of BC service may have lower bit-rate compared with the corresponding regular BC content, hence 
requires lower bandwidth. 

The BC content preview procedures may take place in either one of the following cases: 

1) Multi-screen BC preview: Preview the BC service before the users decide to enjoy it in a fall screen mode, 
where the preview content is provided through a multi-screen mode (e.g. PiP, Mosaic), or 

2) Single-screen BC preview: Preview the specific BC program before the users decide to pay for it, where the 
regular BC service procedures of clause 8.3. 1 apply before some notification or purchase procedure can take 
place. 

NOTE: How the purchase procedure is activated, as well as the concrete flows for a commercial purchase are out 
scope of the present document. 

8.7.1 .1 Session initiation procedures for multi-screen BC preview 

The procedures described in clause 8.3.1.1 apply for multi-screen BC preview session initiation, with the following 
differences: 
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• The initiation request carries the BC service IDs available for preview, and the maximum bandwidth needed 
for muti-screen preview. In case there is a primary stream (i.e. a regular BC service) besides the preview 
streams, the related regular BC service IDs are also carried in the initiation request; 

NOTE: In case of multiple media channels, either a single session can be used to set up all media channels, or one 
session per media channel can be used. In either case, existing procedures for BC session initiation apply. 

• Multiple media channels are established for multi-screen preview, and channel change is enabled for each 
media channel. 

8.7.1 .2 Procedures for transition between multi-screen BC preview and regular BC 

service 

The transition between the multi-screen BC preview and a regular BC service may take place e.g. when one preview 
channel is selected for full-screen viewing. 

The transition can be achieved by the actions of channel switching, channel join or channel leave, e.g. channel 
switching on the primary channel and channel leave/join on the preview channels at the same time. 

The preview session may be modified according to the change on the network parameters, e.g. bandwidth. 

8.7.2 Preview procedures for COD service 

The CoD content preview procedures may take place before the users decide to obtain some particular CoD content. 

The preview content may have its own content identifier to enable the content selection (e.g. from the content guide), in 
which case the preview procedures can refer to procedures specified in clause 8.4. 

The preview content may also share the content identifier with the regular CoD content, while variation of the regular 
CoD content (e.g. segment collection, lower bit-rate transcoding etc.) is delivered to the UE based on criteria such as 
content metadata or policy of service provider. 

In the case of sharing identifier, the additional preview indicator should be present during session initiation procedure 
by the UE, and the MP is informed of preview indicator to deliver content for preview (e.g. segment collections, lower 
bit-rate stream). 

The main procedure for sharing identifier preview complies with 8.4.1 signalling flows for CoD session initiation with 
the following differences: 

1) The session initiation request message initiated by the UE (in step 3 of clause 8.4.1.1) carries additional 
content preview indicator, which indicates that the session request is for CoD preview, not for regular CoD 
viewing. 

2) Upon incoming session initiation request (in step 4 and 5 of clause 8.4.1.1), the SCF identifies the session 
initiation is for content preview and performs service authorization. If the UE is allowed to preview the 
content, the SCF forwards the session initiation request to the selected MF, including the preview indicator. 

3) Signalling procedures for establishment of a content control channel and optionally content delivery channels 
for the content preview take place between the UE and the MF as described in clause 8.4.1.2. MF enforces the 
preview policy and delivers the preview content to UE according to the preview policy. 

NOTE: The preview policy provision on the MF is out of scope. It may be subject to some type of criteria, e.g. 
content metadata. Examples of preview policy include the preview bitrate, time period permitted for 
preview, etc. 

8.7.3 Preview procedures for other IPTV service 

The preview of other IPTV services is similar to preview of BC and CoD. The content to be previewed is identified by 
the IPTV content identifier, see clause I.l. 
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8.8 Parental control procedures 



On receipt of a CoD session initiation request as defined in 8.4. 1 or BC session initiation request as defined in 
clause 8.3.1, the SCF shall chek the following parameters in IPTV user profile in the following order: 

• If the requested content is not compatible with parental control level or PC-ClassificationRestrictionn then the 
SCF shall reject the request. 

• If PC-CostLimit, PC-TotalCostLimit, PC-TotalPlayTimeLimit are exceeded, then the SCF shall reject the 
request. 

• If PC-TimeRestrcition is present If the time and if the request occurs within PC-TimePeriodRestriction range, 
then the SCF shall contact the user indicated in PC -Contact if " dynamic PC-activation" is activated. If not, the 
SCF shall proceed the request as indicated in clauses 8.4.1 for CoD and 8.3.1 for BC. 

• If no PC-TimeRestriction is present and if dynamic PC-activation is activated then the SCF shall contact the 
user indicated in PC-Contact. If not, the SCF shall proceed the request as indicated in clauses 8.4.1 for CoD 
and 8.3.1 forBC. 

In case the SCF has contacted the user indicated in PC-contact, if the answer is positive, the SCF shall proceed the 
request as indicated in clauses 8.4.1 for CoD and 8.3.1 for BC. If the answer is negative or if there is no answer after a 
associated timer has elapsed, the SCF shall reject the request. 

NOTE: Parental control procedure is valid for any services based on CoD or BC procedures (e.g. UGC, N-PVR, 
etc.) 

Figure 34C describes the SCF behaviour regarding parental control. 
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Yes 




Figure 34C: Parental control checkings in the SCF 

During an on-going CoD or BC session, if the PCtotalPlayLimit becomes exceeded, the SCF shall terminate the CoD or 
BC session as defined in clauses 8.3.3 for BC and 8.4.3 for CoD. 

If the session enters the PCTimePeriodRestriction range, the SCF shall apply the procedure from the 
box 'PC-TimePOeriodRestriction present defined in figure 34C. 
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8.9 UGC procedures 

8.9.1 Overview 

There are two types of UGC procedures: 

• creation of the User Generated Content: this type of procedure allows a user to declare and upload/upstream 
his/her own content to the network; 

• watching of User Generated Content: this type of procedure allows a user to select and watch User 
Generated Content. 

NOTE: The clause 8.9.3 UGC watching procedure may start before the clause 8.9.2 UGC creation procedure has 
been completed (see e.g. TS 181 016 [15], clause A.9.1.2, "Use case: Home movie sharing, streaming"). 

8.9.2 UGC creation procedure 

The UGC creation procedure comprises four major steps: 
Step 1: Declaration of User Generated Content 

• The UE sends a User Generated Content creation request to the SCF and receives a content ID for the UGC 
from the SCF. The content ID is independent of the address where the UGC can be retrieved by other UEs. 

Step 2: Publication of User Generated Content information by the UE 

• The UE sends a request to the SCF that contains a description of the User Generated Content (name, type, 
restriction, textual description, special group users, etc.). This request may be combined with the User 
Generated Content Declaration request in step 1. The UGC item described in clause 7.4.1 is used for UGC 
description information carried in the publication request. 

Step 3: Creation of User Generated Content 

• The UE initiates a session with the SCF and MF in order to create the User Generated Content (i.e. 
upload/upstream (unicast) the content to the MF). The MF provides the SCF with the location at which the 
UGC becomes available. 

Step 4: Publication of User Generated Content information by the SCF 

• The SCF establishes the relationship between UGC content ID, UGC description,and optionally the MF, and 
publishes this UGC description information. The UGC description publication by the SCF in step 4 may take 
place before, during or after the UGC content creation delivery session initiation in step 3. 

NOTE 1 : In general, the UGC procedures should allow for all forms of SCF-MF interaction as described in 

clause 5.2. 

Step 1 is always the first step. Step 2 may happen at any time during the UGC creation and can be repeated during the 
lifetime of the content. 

NOTE 2: UE publishes the UGC description to SCF, optionally it may be audited by the SCF or the management 
entities. As a result of this audition the UGC description may be rejected or a revision of the description 
may be required. Also the UGC content may also be audited. The mechanisms for UGC description and 
content auditing are out scope of the present document. 

Figure 34D depicts the typical steps that occur when the UE creates UGC. 
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2A. UGC Description Request 
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Figure 34D: UGC creation 

The UE sends a UGC Declaration Request through the Core IMS to the SCF. 



IB) The SCF records the UGC information and sends a UGC Declaration Response including a UGC content ID 
through to core IMS to the UE. 

2A) The UE sends a UGC Description Request through the Core IMS to the SCF. The request contains a 

description of the User Generated Content (name, type, restriction, textual description, special group users, 
etc.). 

2B) The SCF records the UGC description, establishes the relationship between UGC ID and UGC description and 
sends a UGC Description Response through to core IMS to the UE. 

NOTE 1: Steps 2A/B can be done either after steps lA/lB or combined with steps 1 A/IB. 

3) The UE initiates a UGC creation session, including a content upload/upstream channel to the MF. The content 
upstream procedure is similar to the one defined in 8.4. 1 . 1 . 1 for CoD initiation procedure (steps 3-6 and 9-11). 
The content control channel may not be required. The content upload procedure is specified in 8.18.1. The 
session initiation response from the MF to the SCF includes the location on which the UGC becomes 
available. 

4) The SCF establishes the relationship between UGC ID, UGC description and optionally UGC location 
(address), and publishes this UGC information. 

The UE can modify or terminate the established UGC creation session later on. 

NOTE 2: Updating the SSF for UGC information from the SCF is required, but the method for achieving this is out 
scope of the present document. 
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NOTE 3: In a particular protocol realization, the messages supporting steps 1 and 2 may be embedded in the 
messages supporting UGC session initiation. 

For a UGC creation session initiated by Remote UE, the Remote UE starts-up the UGC content creation service 
according to the procedures of service initiation by remote UE specified in clause 8.25 which indicates the UGC service 
for the Target UE to upload/upstream UGC content. Then the Local UE initiates the UGC creation procedure using the 
same steps in figure 34D. 

NOTE 4: UGC creation by direct multicast from a UE to a multicast group is not supported in this release. 

8.9.3 UGC watching procedure 

The UGC watching procedure comprises two major steps: 
Step 1: Selection of UGC 

• The selection of the UGC may be done through the SSF. Alternatively, UGC selection can be triggered by a 
content recommendation or a notification. The UE may also pre-select UGC that has already been declared 
and published (clause 8.9.2, steps 1, 2 and 4), but not yet created (clause 8.9.2, step 3). 

NOTE: Other ways of selecting UGC (notification from another UE) are out of scope of this release. 

Step 2: Watching of UGC 

• Session initiation can be performed by the UE or the SCF in order to watch the selected UGC. The UGC 
watching session is equivalent to the CoD session. If the UE has previously pre-selected UGC that had already 
been declared and published but not yet created (see above), then this UGC will be delivered in an 
SCF-initiated CoD session (clause 8.4.1, figure 21A) when the UGC is created. 

Figure 34E depicts the typical steps of the UGC watching procedure. 





CORE IMS 




1 UGC selection 



2 Notification of UGC availability 



3 UGC watching session initiation 



UGC watching session modification/termination 




Figure 34E: UGC watching procedure 
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1) The UE can use two methods for UGC selection: 

The UE can select UGC through service selection procedure with SSF (clause 8.2, step 4) For selection 
using the SSF the SSF may restrict the list of UGC depending on user identity and UE capabilities. 

The user can pre-select UGC that has already been declared and published (clause 8.9.2, steps 1, 2 and 
4), but not yet created (clause 8.9.2, step 3). The SCF then stores this pre-selection of UGC. 

2) If the SCF wants to inform the user of UGC availability the SCF can use the notification procedure as defined 
in clause 8.11.1 or recommendation procedure from the SCF as defined in clause 8.13. 

3) The UE or the SCF initiates a UGC watching session. The UGC watching session is equivalent to the CoD 
session. Therefore procedures defined in clause 8.4.1 apply. When the SCF detects that pre-selected UGC 
becomes available (i.e. its creation, as described in clause 8.9.2, step 3, is starting or has been completed), then 
this UGC will be delivered in an SCF-initiated CoD session (clause 8.4.1.1.2). 

When the UE wishes to modify or to terminate the UGC session, it follows session modification/termination procedures 
as specified in clauses 8.4.2.1 and 8.4.3.1. 

NOTE: UGC watching through multicast (e.g. in a BC session) is not described in the present document. Generic 
BC procedures can be reused. 

8.9.4 UGC removal procedure 

The user can decide to remove one of his/her UGC by using UGC description procedure as defined in clause 8.9.2. 

The operator can decide to remove the created UGC at any time due to local or legal policies. It may inform the user 
that has created the UGC by using the Notification procedure as defined in clause 8.11.1.1 or other methods. 

The network shall ensure that the UGC will not be present in the related MF and that UGC description is also removed. 

8.10 Personalized channel (PCh) service procedures 

PCh service allows the users to tune in a single (virtual) channel and watch one or multiple pre-configured content items 
identified in the service profile (PCh information). 

Before the PCh service is available to the user, the configuration procedure shall take place, through which particular 
IPTV content items identified by their IPTV content identifier, see clause I.l, are selected and scheduled in the PCh 
information. 

The UE retrieves the specific PCh information from the SSF via service selection procedure as described in clause 8.2. 

Before the user can view the content items in the PCh information, a session initiation procedure for the PCh service 
shall take place. 

8.1 0.1 Generic Procedure for PCh service 

Figure 34F shows the major steps enabling the PCh service. 
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Figure 34F: Major steps for PCh service 

1) The PCh declaration procedure takes place between UE and SCF. The UE sends a PCh Declaration Request to 
the SCF via Core IMS, and the initial PCh information, containing the PCh id, is created and returned based on 
user profile and content metadata. 

2) The PCh Configuration procedures takes place between SCF and UE (e.g. add an item to the list, remove an 
item from the list, arrange the schedule), as described in clause 8.12 upon user's decision. The SCF saves the 
PCh configuration, e.g. the time schedule for each PCh content item. SCF may accept or reject the overlap 
between content items. In this release overlap between broadcast items shall be accepted during the 
configuration phase. Overlap between a broadcast content and a CoD content shall not be accepted during the 
configuration phase. Overlap shall be handled in accordance with one of the following options: 

a) The network automatically records the new content and maintains the ongoing content. 

b) The network switches to the new content, bookmarks the old content and/or starts recording the old 
content. 

C The network advises the user that makes the decision if the network supports either of the above options. 

3) The selection procedure of PCh information takes place either between UE and SSF as described in clause 8.2 
or notification procedures between UE and SCF as described in clause 8.11.1 or recommendation procedures 
as described in clause 8.13. During this step, the UE retrieves the PCh id and other necessary network 
parameters (e.g. the bandwidth requirement) to facilitate the initiation of PCh session (i.e. step 3). Optionally 
the time schedule can be also provided in this step. 

4) The PCh service provision procedures take place after the selection of the PCh information. This step shall 
conform to one of the following options: 

a) The PCh service is provided through a single unicast session for all content items inside the specific PCh, 
including BC. The procedure for this case is described in clause 8.10.2. 

b) The PCh session alters between unicast and multicast under control of the SCF. The procedure for this 
case is described in clause 8.10.3. 

8.1 0.2 MF Option for PCh Service Provision 

Figure 34G depicts the PCh service procedure that utilizes a single unicast session for all PCh content items, including 
BC. 
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Figure 34G: MF option for PChi service provision 



1) The PCh session initiated by the UE, as similar with the one defined in 8.4. 1 for CoD initiation procedure with 
the following differences: 

The session initiation request from the UE contains the PCh id as the CoD content id. 

The SCF retrieves the PCh information (e.g. list of content to be played with the time schedule of each 
item) and sends it to the selected MF in addition to the PCh ID. The SCF may send either part of the PCh 
list (e.g. the first item) or the entire PCh information to the MF, for the purpose of content channel 
negotiation. 

2) When there is overlap between two PCh content items, the SCF handles the conflict items according to the 
selected policy by the SP as per clause 8.10.1. In this step, the SCF triggers the N-PVR procedures for 
recording of either the upcoming item or the on-going item according to the SP policy. 

NOTE 1 : The rest of the call flow assumes there is no overlap. 

3) Based on the current time, the SCF sends PCh control message to the MF via Core IMS, indicating the 
delivery of the upcoming PCh content item. The PCh control message contains the upcoming PCh item id(s) 
within the PCh list, as well as the time schedule of each item. 

NOTE 2: The PCh control message is used when the SCF does not send all of the PCh information to the MF in 
session initiation (i.e. in step 1). 

4) The PCh session may be modified if the reserved resource is not sufficient for the upcoming PCh item, e.g. 
due to higher bandwidth requirement. In this case the MF-initiated session modification procedure described in 
clause 8.4.2 applies. 

5) The indicated PCh content is delivered to the UE through the unicast content delivery channel established 
during step 3. The MF needs to fetch the content in from MDF or from other content sources. The MF may 
also perform the content adaptation or conversion before the unicast content is sent out to UE, e.g. 
multicast-unicast conversion, transcoding, etc. 

NOTE 3: The steps 2 to 5 can be repeated during the life time of PCh session, for the purpose of switching among 
multiple content items. 

NOTE 4: How the MF fetches the PCh content item from the content source is out scope of the present document. 
In specific implementations, the MF contacts the source via file transfer or joins a BC multicast group to 
receive the indicated content. 
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6) Initiated by the UE or the network, the PCh session is terminated at some time, as the ones defined in 
clause 8.4.3. 



8.1 0.3 UE Option for PCh Service Provision 



Figure 34H depicts the signalling flow for UE option of PCh service provision, which enables the SCF to control UE to 
alter the PCh session between unicast and multicast depending on the type of viewed item. 
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Figure 34H: UE option for PChi service provision 

1) The PCh session initiated by the UE according to the type of first PCh content item in the PCh information, 
i.e. BC session initiation described in clause 8.3.1, or CoD session initiation described in clause 8.4.1. The 
session initiation request contains the specific PCh id and the first CoD content id/BC service id. 

After the PCh session initiation, the UE receives the indicated content through the delivery channel. 

Note that the UE may also have the content information stored locally. 

2) When there is overlap between two PCh content items, the SCF handles the conflict items according to the 
selected policy by the SP as per clause 8.10.1. In this step, the SCF triggers the N-PVR (or C-PVR) procedures 
towards the MF (or UE) for recording of either the upcoming item or the on-going item according to the SP 
policy. 

Note that the UE client in this case will be coordinated to follow the SP policy as well. 

NOTE 1 : The rest of the call flow assumes no overlap. 

3) The SCF sends UE the PCh control message carrying the control command (e.g. item switch, PVR, etc.) and 
upcoming content id(s) that are to be handled. 

Note that the UE may also have the content information stored locally. 

4) The procedures are initiated according to the PCh control message, for example, switch to another multicast 
group for BC item (4a), initiate a session modification for upcoming CoD item (4b), perform PVR service as 
described in clause 8.5 (4c), etc. 

NOTE 2: The steps 2 to 4 can be repeated during the life time of PCh session, for the purpose of switch among 
multiple PCh items. 
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5) Initiated by the UE or the network, the PCh session is terminated at some time, as the ones defined in 
clauses 8.3.3 or 8.4.3 with respect to the type of the latest PCh content item. 

NOTE 3: The pure UE centric PCh, where the PCh control decision is made locally on the UE without interaction 
with the network, is out scope of the present document. 

NOTE 4: The PCh control message can be session modification request (e.g. SIP re-INVITE, etc.) or non-stateful 
message exchange (e.g. SIP INFO,etc.), and should be determined in the protocol implementation phase, 
which is out scope of the present document. 

8.1 1 Interaction procedures with other IPTV Services 
8.1 1 .1 Notification procedures 

Notification procedure can be used for several purposes: notification that a CoD is available based on user's prior 
subscription to that information, caller-Id on TV screen, reminder from a particular TV program based on user's setting 
etc. 



8.11.1.1 



Notification procedures using signalling path 



Figure 35 depicts the typical steps that occur when the SCF wants to notification the user on a particular event using 
signalling path. 
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Figure 35: notification procedure using signalling path 

Priori to the procedure, it is considered that the SCF has detected an event that would cause the notification to be sent to 
the UE. For example, it can be informed of an incoming call to the user. It could also be based on user's subscription 
dealing with a notification to be sent when a particular BC program/CoD content is available. 

1) Based on the service logic, the SCF sends an Notification Request to the UE via the core IMS. The message 
shall contains at least: 

i) the reason of the notification: Examples include incoming phone-calls, CoD content or TV program 
notification based on reminder/subscription set by the user; 
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ii) related parameters: Examples include calling-number/URI, CoD content identifier or BC service ID, 
service provider id of the associated SSF fi-om where the update service information may be retrieved, 
etc. 

2) The core IMS forwards the Notification Request to the UE. 
NOTE: The Notification may be displayed to the user. 

3) The UE answers to the SCF via the core IMS. 

4) The Notification Response is forwarded to the SCF. 

After this step, the UE can take appropriate action (e.g. initiate a CoD session) based on user's decision. 



8.11.1.2 



Notification procedures using multicast media path 



Figure 35A depicts the steps that occur when the SCF and MF use the multicast media path to send a notification to 
users who are watching a specific BC channel. 
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Figure 35A: notification procedure using multicast media path 

When receiving a notification trigger event from external entity (e.g. SCF in charge of BC service) or detecting an 
internal notification trigger (e.g. SCF detects that it should send a notification to users who have subscribed to the 
content recommendation service for an upcoming BC program) or receiving a message need to be delivered using 
media path, the SCF would send notifications to users who are watching a specific BC channel. If the users want to 
receive the notification, they will have joined the specific notification multicast stream in addition to the BC service 
multicast streams. 

1) SCF sends the notification to the selected MF (e.g. SCF retrieve MF from local configured information) via 
Core IMS. The notification request shall contain at least: 

i) The reason of the notification: e.g. upcoming programs, floating ad or weather forecast. 

ii) Related parameters: e.g. BC service ID, service provider id, etc. 

NOTE 1: As stated in TS 182 006 [2], an Application Server may originate requests to a destination without 
involving the S-CSCF. This capability should be used if SCF sends the notification to MF directly 
without Core IMS involved 

2) MF delivers the notification to the specific notification multicast group. 
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NOTE 2: The multicast address for the notification channel may be pre-configured on the MF or it may get it from 
the notification request in step 1 . Other options may be possible and out of scope of specification. 

3) The UE receives the notification from ECF/EFF and displays the notification to the user. 

NOTE 3: Before step 3 could take place, UE should first discover the specific multicast group information for the 
notification (e.g. through the Service Discovery and Selection procedure) and then join the notification 
multicast group. 

The UE can take appropriate action based on the user's decision. 

8.12 Procedures for IPTV User Profile Configuration 

This clause describes the generic procedures for IPTV user profile configuration. These procedures may be used in 
conjunction with other procedures for delivery of other IPTV services - e.g. Content recommendation service, N-PVR. 
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Figure 35B: User Profile Configuration procedures 

1) The user (on UE) makes a request to the SCF to configure IPTV User profile settings. 

2) The SCF shall perform relevant authentication and authorization of the User Profile Configuration request by 
the user before permitting the request. The SCF records the profile settings as part of the IPTV user profile 
information as described in clause 7.3.1. 

NOTE: In case the UE needs to directly contact a network functional element, (e.g. Service Control Function), it 
should perform GBA authentication, for key management purposes, during the session start-up phase. 
Please refer to TS 187 003 [5]. 

3) The UE is informed of the result of the IPTV user profile service configuration request. 

8.13 Content Recommendation service procedures 

The Content Recommendation Service (CRS) is used for providing recommendations to IPTV users or user groups. 

The content recommendation service may make recommendations to user/groups based on different criteria which 
include user profile e.g. preferences settings, current viewing habits of user, etc. 
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The CRS service procedures include 3 major steps: 

1) CRS event detection. The events include request from the UE, new content arrival notification, presence 
update, trick play reports from MF, channel change report from UE etc. This step is triggered due to the user 
subscription or service provider's policy, and it may also be based on user request (e.g. for sepecific program 
or during specific time period). 

2) CRS infc)rmation generation for specific user. The CRS info includes one or more IPTV content identifiers 
(clause I.l), identifying the recommended content. The user profile (e.g. user preference, watching habits, etc.) 
is used for filtering/sorting of CRS info. 

3) CRS information delivery to the UE. SCF sends the generated CRS information to specific UE(s). 

In the case when user profile settings are used for making content recommendations, the user preferences in IPTV 
profile are configured using procedures described in clause 8.12. 

The CRS information is delivered to the UE by the SCF using notification procedures as described in clause 8.11. The 
UE may subsequently fetch the details about the recommended content from the SSF via procedures described in 
clause 8.2. 

Figure 35C depicts the typical steps for CRS. 
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Figure 35C: signalling flows for CRS provided by SCF 

1) UE may optionally send a request to the SCF for CRS information notifications. 

NOTE 1 : This step is optional in case the user only wants to get notified during specific content play back or 
specific time period. 

2) The SCF detects the CRS events based on user profile, user request or service provider's policy. 

3) The SCF generates the requested CRS information for specific user. The CRS information includes one or 
more identifier(s) of the recommended content. 

NOTE 2: How to generate the program related CRS information on the SCF is out scope of the present document. 

4) SCF sends UE the generated CRS information using notification procedures described in clause 8.11.1.1. 
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8.14 Advertising (Ad) service procedures 

There are several types of procedures in Advertising (Ad) service, including: 

1) Targeted ad insertion: some selected ad content is provided to the UE during the IPTV content playback, 
based on the user profile (user preference, shopping habits, location information, etc.) and the IPTV service 
status (e.g. current BC program, commercial breaks or pause during content playback). Content replacement or 
multi-window rendering takes place within the insertion time period. 

2) Pull mode Advertising: Advertising is content in its own right and can be selected by the UE, and the users 
can actively retrieve or interact with the ad content. Audio-visual content of this ad type can be provided to the 
users via similar procedures with CoD or BC. Other procedures for non audio-visual ad content provision, 
such as interactive ad and banners, may also be described here 

3) Broadcast based Ad-insertion: Ad content (local or regionalized) is inserted into the IPTV content that is 
broadcasted to the UE without factoring in any information related to user profile. Such ad content is not 
targeted any any specific user or user groups but it may be targeted to regions or zones depending on network 
topology. 

NOTE 1: Other procedure types of Ad service can be included. 

Where Targeted Ad Insertion (TAJ) is required. Ad procedures shall follow the generic procedures in clauses 8.14.1 and 
8.14.2, implemented according to one or more of the following options: 

• Internal option in which advertising tasks are done by entities within the TISPAN IPTV system 
For the internal option, refer to clause E. 1 . 

• External option in which an external Advertising sub-system is interconnected with TISPAN entities 
For the external option, refer to clauses E.2 (SCTE) and/or E.3 (OMA MobAd). 

NOTE 2: In the second option, the SCF acts as a broker to bundle information from IPTV user profile and service 
profile along with information on placement opportunities and sends it over to the external advertising 
sub-system which responds back to SCF with the ad-placement decisions decisions. 

• Implementation examples of these options are documented in clauses E and F. The upcoming clause discusses 
a generic architecture that can be instantiated into any of the options in clauses E and F. 

8.14.1 Generic Procedures for targeted ad insertion (TAI) 

Ad insertion implies that an IPTV sesssion exists prior to the insertion time. The targeted ad is selected by the SCF with 
regard to user profile (e.g. shopping habits) or other criteria, e.g current BC program. 

IPTV content and ad content in the context of ad insertion can be described as: 

• IPTV content: the content to be partially (or entirely) replaced during the IPTV session. There is usually some 
cue/hint related to the IPTV content used to trigger ad insertion, e.g. insertion time in content metadata or 
insertion points in the actual content itself where a targeted ad can be inserted to replace an existing default ad. 

• Ad content: the content which is inserted to the IPTV content during the ad insertion time, or to replace a 
default ad. The ad can be rendered sequentially or in parallel with the IPTV content. 

The ad insertion can be performed at either UE side or MF side: 

• When UE performs ad insertion, it is informed of ad insertion indication, it can receive both IPTV content and 
ad content at the same time, and renders them in a sequential or simultaneous way. The UE could also have the 
ad content stored locally through off-line means. 



• 



When MF performs ad insertion, it is informed of ad insertion indication, it can retrieve or receive the ad 
content, and delivers the combinded IPTV stream and ad to the UE. 
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The major steps of TAI is as follows: 

1) IPTV service status detection/awareness: 

There are several options in this case: 

the SCF can be fully responsible for the awareness/detection of the user's IPTV service status, in which 
case, the SCF shall reuse the existing procedures for that purpose (see clause 5.5); 

optionally the MP can be fully responsible for the awareness/detection given that the MF is in the 
signalling and the media control path and can be informed of media embedded events related to ad 
insertion; 

additionally the UE can be fully responsible for the awareness/detection using its local state for that 
purpose; 

Finally, a service provider can use a hybrid approach where some events are detected by the SCF while 
others are detected by the MF, and/or the UE. 

2) Identification of Targeted Ad Insertion Points: 

Places to insert Ad could be known in advance (predetermined) or detected during the play (unexpected). 
More details on Ad placement in annex G. 

3) Ad Content Selection: 

One or more ad content(s) is selected with regard to user profile (e.g. shopping habits, user preference, etc.). 
The user's IPTV service status and/or the metadata of current content can also be used for locating of ad 
content targeted to specific user or user group. 

4) Ad content delivery: 

The selected ad content is delivered to the UE, before or after which essential ad insertion is performed (i.e. 
either at MF side or UE side). 

8.1 4.2 Generic Signalling for Targeted Ad insertion 

NOTE: The term Ad Server is used for the generic purpose of Ad selection and/or control, and it can be 
implemented in SCF or externally, based on the examples in annex E. 

8.1 4.2.1 Signalling flows for TAI at UE side 

When the ad insertion takes place at UE side, the UE is informed about ad insertion information from SCF. The UE 
may initiate individual session request for Ad content, which implies that multiple sessions exist on the UE during the 
ad insertion time. Other means for retrieving the content are also envisioned. 

Figure 36 depicts the typical steps when UE is informed of targeted ad insertion information. 
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Figure 36: Signalling flows for UE performing TAI 

1) An IPTV session is established between UE and SCF in charge of general IPTV services as described in 
clause 8, e.g. BC session in clause 8.3.1.1, CoD session in clause 8.4.1.1, etc. and the related IPTV content is 
delivered to the UE. 

2) The service state of on-going IPTV session is detected on the SCF, MF or UE (e.g. the current IPTV content 
identifier (clause I.l), the commercial break of the program, the trick-play events, etc.). Detection of the IPTV 
service state at the SCF is done based on IPTV Service State Data (see clause 5.5) or using IPTV Presence 
information (see clause 9.1). Note that for simplicity, the figure does not show the option when the service 
state detection happens at the UE. 

3) The Ad Server is informed of the ongoing IPTV service state of the specific user detected by SCF/MF/UE and 
decides to trigger ad insertion. This step isimplemented depending on the selected option in annex E. Note that 
for simplicity, the figure above does not show the option when the UE contacts the Ad Server with state 
information. 

4) The Ad Server selects the appropriate target ads which can be inserted in the currently streamed content. 

5) The notification procedures specified in clause 8.11.1 are applied to deliver the ad insertion information to the 
UE. This step is implemented depending on the selected option in Annex E. The ad insertion information can 
include the selected ad content identifier, insertion time (begin time and/or length), and other information 
needed for ad insertion. Other means for conveying the same information are also possible 

6) In order to retrieve the ads, the UE may perform session modification procedure in case the MF for the target 
ads is the same MF from which the streaming of the actual content occurs. Alternatively, the UE may also 
initiate a separate session to MF that includes the target ad content. During this step the procedures described 
in clauses 8.3.1 and 8.3.2 for BC session or 8.4.1 and 8.4.2 for CoD session applies. 

NOTE: Other means such as off-line mechanisms can be also used to deliver the target ads to the UE, which are 
out of scope of the present document. 

7) The UE performs the ad insertion, i.e. renders the ad content embedded within the actual content or in parallel 
with the ongoing IPTV content (e.g. in PiP). 
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8) When the ad insertion time is up, the session for ad content is released as procedures described in clauses 8.3.3 
or 8.4.3, and UE resumes the rendering of the IPTV content. 

8.1 4.2.2 Signalling flows for TAI at MF side 

When the ad insertion takes place at MF, the MF is informed of the ad insertion information from the SCF. The MF 
performs the ad insertion, i.e. delivery ad content to the UE during the ad insertion time of IPTV content play back. 

Figure 37 depicts the typical steps when MF is informed of the ad insertion indication. 



UE 



Core 
IMS 



SCF 



MF 



1 Session initiation (clause 8.3.1.1, 8.4.1.1, ...) 



I 




2 IPTV service state detection 



3. State informed to Ad Server 



I 



4 Ad content 
selection 



5 Send ad insertion information to MF 



I 



6 Ad insertion 



7. Ad content delivery 



Figure 37: Signalling flows for MF performing TAI 

1) An IPTV session is established between UE and SCF(BC/CoD/. . .) as described in clause 8, e.g. BC session in 
clause 8.3.1.1 CoD session in clause 8.4.1.1 etc. and some IPTV content is delivered to the UE. 

2) The service state of on-going IPTV session is detected on the SCF or MF (e.g. the current BC program ID, the 
commercial break of the program, the current CoD content id, the trick-play events, etc.). Detection of the 
IPTV service state at the SCF is done based on IPTV Service State Data (see clause 5.5) or using IPTV 
Presence information (see clause 9.1). 

3) The Ad Server is informed of the ongoing IPTV service state of the specific user detected by SCF/MF and 
decides to trigger ad insertion. This step is implemented depending on the selected option in annex E. 

4) The Ad Server selects the appropriate target ads which can be inserted in the currently streamed content. 

5) The ad insertion information is sent to the MF. This step is implemented depending on the selected option in 
annex E. The ad insertion information can include the selected ad content identifier, insertion time (begin time 
and/or length), and other information needed for ad insertion. The means by which the MF acquires the ad 
content is outside scope. 

6) The MF performs the ad insertion, i.e. insert the ad content to the on-going IPTV content or replace the default 
ad content. The MF may perform transcoding or initiate session modification if the network parameters 

(e.g. codec or bandwidth) of ad content are not supported by the UE. 

7) The ad content is provided to the UE during the ad insertion time, or the streamed content includes the ads. 
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NOTE: Group-based TAI, which targets the specific group among the users watching the same BC service, 
should also be considered but is out scope of the present document. 

8.1 5 Procedures for inter-destination media synchronization 

8.15.1 IVISAS-SC 

8.1 5.1 .1 SCF-based media synchronization 



8.15.1.1.1 



Mapping 1 : SO in UE 



Figure 38 provides an overview of the information flows for inter-destination content synchronization according to 
Mapping 1 from clause 5.4.2. 
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Figure 38: Procedure for inter-destination content synchronization 

(1) IPTV session initiation, e.g. BC session initiation according to clause 8.3.1.1, or CoD session initiation 
according to clause 8.4.1.1. 

The following steps (2) to (8) are all tunnelled over the broadcast session established in steps (1). 

(2) The UE (SC) sends a synchronization initiation request to the SCF (MSAS), indicating that it wants to 
participate in the inter-destination synchronization process. The request includes the IPTV content identifier 
(see clause I.l), identifying the to-be-synchronized content. The synchronization group identifier 
(SyncGroupId), in combination with the IPTV content identifier, identifies the group of UEs (SCs) that is 
synchronized as a group for the identified IPTV content. 
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NOTE 1 : The ways that a UE can obtain a SyncGroupId are similar to obtaining a phone conference id. For 

example, one user can request a new SyncGroupId through an off-line process, and share it with other 
users through an offline process. If the group of users does already have a group identifier, e.g. a phone 
conference id, they may reuse this identifier. Clause 8.21.3 describes the reuse of the SSC room identifier 
for this purpose. 

(3) The SCF confirms the participation of the UE in the inter-destination synchronization process. 

(4) The UE (SC) sends its synchronization status information to the SCF. 

(5) The SCF aggregates synchronization status information from multiple UEs (SCs) and calculates the 
appropriate synchronization settings for each UE (SC). 

NOTE 2: Examples of algorithms to calculate the synchronization settings instructions from collected 
synchronization status information may be found in [i. 11]. 

(6) The SCF sends a synchronization settings instruction to the UE (SC). 
Steps (4) - (6) may be repeated at regular time intervals. 

(7) The UE sends a synchronization termination request, indicating that it is no longer active in the 
inter-destination synchronization process. This could be e.g. because of a channel change by the UE. 

(8) The SCF confirms the termination of the UE's participation in the inter-destination synchronization process 

NOTE 3: The UE can initiate and terminate multiple synchronization sessions within a broadcast session, both 
consecutive and simultaneous. 

The above procedures are generally applicable to all IPTV services (BC, CoD, N-PVR, Ad, UGC, Shared Content, etc.) 
with the IPTV content identifier in step (2) identifying the to-be-synchronized content. 

8.15.1.1.2 Mapping 2: SC in Transport 

The procedures according to Mapping 2 from clause 5.4.2 are the same as above with the following changes: 

• Step (1) is not applicable. 

• Tunnelling over the broadcast session is not applicable. 

• The MS AS is an elementary function of the SCF or a stand-alone (possibly distributed) functional entity. 

• The SC is an elementary function of the Transport Functions. 

• The request in step (2) includes a media stream identifier. 

• The SyncGroupId may be used to identify multiple synchonisation groups, or it may be populated with the 
value "default". 

NOTE 1 : How the SC obtains the SyncGroupId is not described in the present document. 

NOTE 2: If the MSAS serves SCs according to both Mapping 1 and Mapping 2 for a specific IPTV service, then 
the MSAS has to correlate the IPTV content identifier (BCServiceld, CoDId, etc., see clause I.l) in 
Mapping 1, with the appropriate media stream identifier in Mapping 2. 

8.15.2 MSAS-SC 

Figure 38A shows a flow for the exchange of synchronization status information between a media-stream-modifying 
Synchronization Client (SC) and an MSAS. 
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Figure 38A: Media synchironization in case of media-stream-modifying SC 

(1) The MS AS sends a synchronization initiation request to the media-stream-modifying SC, indicating that the 
SC will participate in the inter-destination synchronization process. The request includes an identification of 
the to-be-synchronized media stream(s). 

(2) The SC confirms its participation in the inter-destination synchronization process. 

(3) The SC sends synchronization status information on the synchronicity relationship between incoming and 
outgoing media streams to the MS AS. 

(4) The MSAS returns an acknowledgement message to the SC. 
Steps (3) - (4) may be repeated at regular time intervals. 

(5) The MSAS sends a synchronization termination request, indicating that the SC is no longer active in the 
inter-destination synchronization process for the identified media stream(s). 

(6) The SC confirms the termination of its participation in the inter-destination synchronization process 

8.1 6 Signalling flows for network-controlled trick play 

Figure 39 provides the signalling flow for controlling trick play of a Broadcast TV channel, CoD, N-PVR or other IPTV 
session by a network element. In order to apply trick modes to a Broadcast TV channel, a BC TV with trick play session 
must first be established. 
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Figure 39: Signalling flow for network-controlled trick play 

1) Broadcast TV, CoD or N-PVR session initiation. 

NOTE 1: The Broadcast TV, CoD or N-PVR sessions are initiated by the appropriate procedures in clauses 8.3.1.1, 
8.4.1.1 and 8.5.2, respectively. 

2) Based on an event detected by the SCF, e.g. a trigger received from an external application, the SCF sends a 
notification to the UE to request stream control. The notification procedure from clause 8.11.1.1. shall be 
applied. The notification response includes media action data. 

3) If the existing session is a Broadcast TV session, a transition from BC TV to BC TV with trick play takes 
place according to clause 8.3.5. 

4) The UE uses the content control channel to perform the trick play command, e.g. "pause", "fast forward", etc. 

NOTE 2: How the SCF is triggered by external applications and how media action data is sent from the SCF to 
external applications is not described by this procedure. 

8.17 Push Procedures 
8.17.1 Push CoD session 

Push CoD session comprises two main steps: 

• Step 1 : The SCF initiates the CoD content download from MF to UE. The detailed procedure can be referred 
to clause 8.18.2. 

• Step 2: The UE selects the media content in its storage device which has been downloaded from MF and views 
it. 

NOTE: The content is stored on the UE after step 1, hence in step 2 it is not required to have any further 
interactions between the UE and the network entities to either access or play the content. 
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8.18 Unicast Content Upload/Download Procedures 

The procedures described here are for upload/download cases distinguished from streaming cases (described in 
clause 8.4). 

NOTE: The generic content upload/download procedures described below can be referred by IPTV services such 
as UGC upload/download, Ad, etc. 

The unicast content upload/download session may be initiated by either by UE or SCF. 

8.18.1 Signalling Flows for UE-initiated Unicast Content Upload/Download 

Figure 39A depicts the typical steps that occur when the UE initiate a request to upload/download content by unicast. 
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Figure 39A: UE-initiated unicast content upload/download session initiation 

1) The UE initiates an upload/download request to the SCF. 

2) The session initiation request is routed by the Core IMS entities up to the SCF. 

3) The SCF performs service authorization. If the UE is allowed to upload/download contents, the SCF forwards 
the session initiation request to the selected MF which handles media content upload/download. 

4) Signalling procedures for the establishment of content upload/download channel take place between the UE 
and the MF. The procedure of content channel negotiation is similar as the one defined in clause 8.4.1.2.1, but 
the media control channel is not needed here. During the negotiation, the MF offers UE the location of the 
uploading/downloading content for content upload/download. 

5) The MF confirms the establishment of the dialogue with the UE. 

6) The SCF sends this confirmation to the Core IMS. 
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7) The P-CSCF within the Core IMS interacts with the RACS to commit all resources previously reserved. This 
includes opening pinholes for exchanging content delivery. 

8) The P-CSCF forwards the dialogue confirmation to the UE. 

8.18.2 Signalling Flows for SCF-initiated Unicast Content Download 

Figure 39B depicts the typical steps that occur when the SCF initiate a request to download content by unicast. 
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Figure 39B: Signalling flows for SCF-initiated unicast content download 

1) The SCF identifies the media content which will be downloaded to the UE, and then sends a download session 
initiation request to the UE (described in clause 8.4.1.1.2 from step 1 to step 4). 

2) The UE check if it will accept the media content. 

NOTE: The checking criteria can include one or more methods such as its storage capability to compare with size 
of the media content, the configuration of the UE if it will accept the media content, the selection of the 
User if the user accepts the content. 

3) If the UE accepts the request, signalling procedures for establishment of media content download channel take 
place between the UE and the MF based on the procedures in clause 8.4.1.2.2. 

4) The UE confirms the establishment of the dialogue with the SCF and commit the resource previously reserved. 

(described in clause 8.4.1.1.2 from step 6 to step 11). 

5) After this point, the selected MF can deliver the media content to the UE (ie. media content download to the 
UE). UE saves it in its storage device. 
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8.19 Multicast Content Download Procedures 

Multicast Content Download Procedures are out of scope of the present document. 

8.20 Signalling flows for restricted trick play 

The restricted trick play procedure can be used by network to disallow specified trick play functions on any segment of 
the content. 

Figure 39C depicts the typical signalling flow of restricted trick play. 
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Figure 39C: procedure of restrict tricit play 

1) Broadcast TV with trick play, CoD session initiation or other IPTV session initiation. The Broadcast TV with 
trick play session use the procedures specified in clauses 8.3. 1. 1, and the CoD session use the procedures 
specified in clauses 8.4.1.1. 

2) SCF acquires the restriction policy on trick play according to the information of initial request, e.g. the IPTV 
content identifier (clause I.l), user ID. 

NOTE 1 : For example, SCF may fetch the pre-configured restriction policy from the content metada based on the 
IPTV content identifier; SCF may also generate the restriction policy based on the user subscription data 
and/or the IPTV content identifier. 

3) SCF transmits restriction policy to MF, and informs MF to implement restriction. 

4) When the MF receives UE's content control requests specified in clause 8.4. 1 . 1 . 1 (Signalling flows for CoD 
session initiation), MF executes the restricted trick play according to the policy, such as deny return a 
forbidden response to UE in case trick play is disallowed. 

NOTE 2: The steps 2 and 3 may happened at any time during or after the step 1 initiation session. 
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8.21 Shared Service Control (SSC) procedures 
8.21.1 Overview 

Shared Service Control procedures allow a group of users sharing the control commands related to a service (e.g. BC, 
CoD) and correlating the sessions related to the same service. 

The virtual place established to share the services is called an SSC room. This room has only one service running at a 
time; this service may be BC/CoD/UGC/N-PVR/PCh services as defined in the present specification. In the following, 
details are worked out for shared BC and CoD services only. 

Figure 39D gives an example of shared service control between two users. 



SIP SESSION B 




Figure 39D 



SSC procedures comprise three types: 



• creating an SSC room: this type of procedure allows a user to create an SSC room, indicating a list of users 
associated to the room, policies and related rights. Optionally, the room is associated with a specific service. 

• selecting and entering an SSC room: this type of procedure allows a user to select an SSC room and to enter 
it. Optionally, a service is selected (e.g. BC, CoD), linking it to a room. The procedure ends with initiating the 
related session. 

• controlling the service: this type of procedure allows a authorised user to perform service control commands 
(e.g. trick-play, channel change) to the service associated to the room. 



8.21 .2 Room creation procedure for SSC 



Figure 39E depicts the typical steps that occur when the UE creates an SSC room and publishes related information. 
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Figure 39E: SSC Room Creation procedure 

1 A) The UE sends a SSC Room Creation Request through the Core IMS to the SCF. This request may contain 
information such as: 

the service identifier if the room is associated with only one service item; 

and optionally additional information such asa list of users allowed to join the room and associated rights 
through an SSC room policy as described in annex B (e.g. trick-play authorisation on the content, 
initiation of a service linked to the room). 

IB) The SCF checks if the user has the rights to create the room and records the SSC room information. It sends an 
SSC Room creation Response including the SSC room identifier through to core IMS to the UE. 

2) Publication of SSC room information is performed by informing the SSF, by triggering the SCF to send a 
notification or recommendation, or by sending a message to appropriate other UEs. 

3) The SCF may optionally publish the information about this new SSC room to the users in the list indicated in 
SSC room creation request. 

NOTE: This procedure can be repeated when the service is being shared in order to update SSC room information 
e.g. by updating the SSC room policy. In that case the request will indicate the SSC room identifier. 

8.21 .3 Room selection procedure for SSC 

The room selection procedure comprises the following steps: 
Step 1: SSC room selection 

• Using the SSC room identifier, the UE selects the room it wants to join and retrieves associated parameters, 
such as the SSC room policy. 

Step 2: Entering the selected SSC room 

• The UE enters the room and initiates a service session. If no service is associated with the room at the time of 
entering, the UE first selects a service. 

Figure 39F depicts the typical steps that occur during the room selection procedure. 
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2. select a service for SSC 



3. initiate a service for SSC 



Figure 39F: room selection procedure for SSC 

1) The UE selects a SSC room based on the room identifier and as defined in step 2 of the room creation 
procedure through: 

service selection procedure with SSF as defined in clause 8.2 step 4; 

notification procedure from SCF as defined in clause 8.11.1, recommendation procedures as defined in 
clause 8.13; 

messaging procedure with other UE as defined in clause 9.3. 

The response includes information of the SSC room, e.g. service id currently being watched in the SSC room, offset of 
the content at the present and the SSC room policy. For CoD, the CoDOffset from SAD is included in the room 
selection response so the UE can calculate the media offset. 

NOTE 1: Handling the case where the UE is not authorized to receive SSC room information depends on the room 
selection procedure involved. In case of SSF selection, the SSF can perform personalisation such that 
only allowed SSC rooms are sent to the UE. In case of notification or recommendation, the SCF will not 
send notifications to UEs that are not allowed to enter that SSC room. In case of message exchanges 
between UEs, if a UE sends the SSC room ID to another UE that is not allowed to enter the room, this UE 
will blocked when trying to enter the room. A message may be displayed to the user in this case. 

2) Optionally, if no service is active in the SSC room, the UE selects a BC, CoD, UGC or N-PVR service 
through: 

service selection procedure with SSF as defined in clause 8.2 step 4; 

notification procedure from SCF as defined in clause 8.11.1; 

recommendation procedures as defined in clause 8.13; 

messaging procedure with other UE as defined in clause 9.3; or 

IPTV Content Marker Retrieval procedure as defined in clause 8.23.2. 
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3) In case of CoD, N-PVR or UGC, each UE that enters the room initiates a CoD/N-PVR content/UGC watching 
session indicating the selected content as defined in clauses 8.4.1 for CoD, 8.5.1.2. for N-PVR and 8.9.3 for 
UGC. It additionally indicates a SSC room identifier. In addition to rights checking described in clauses 8.4.1 
for CoD, 8.5.1.2. for N-PVR and 8.9.3 for UGC, the SCF shall check if the user has the rights to enter the 
room, which includes SSC room member authorisation and Service ID check,. If a session has already been 
established by another UE within the same SSC room, the SCF shall correlate this session with the new one 
using the SSC room identifier and selects the same MF. It shall indicate to the MF that this session has to be 
correlated with the other within the same SSC room ID. For an ongoing CoD service, if the CoDOffset 
received in the room selection response is not sufficient, each UE that starts sharing the service can request the 
media offset directly from the MF over the media control channel, once the service has been initiated. 

NOTE 2: the SCF can also select an MF for each UE, similar to the non-shared case. 

In case of BC, if a BC session has not been established by the UE, then each UE that wants to enter the room 
initiates a BC session indicating the selected content as defined in clause 8.3.1. It additionally indicates a SSC 
room identifier. The BC channel indicated in the session initiation request shall be the one of the shared 
channel. If a BC session is ongoing, the UE shall switch to the channel being watched by other users of the 
same SSC room as defined in clause 8.3.4 and shall indicate to the SCF which channel is being watched and 
the SSC room identifier. The SCF shall check if the user has the rights to be part of the group of users sharing 
the control. 

Optionally, the SSC room policy is pushed towards the MF. 

If synchronization is needed for sharing content, the procedures in clause 8.15 shall be applied and the SyncGroupId 
shall be populated with the SSC room identifier. 

The session initiation should be forwarded to the same SCF for the different UE that wants to enter the room. If not, this 
requires synchronisation procedures between SCFs that are not specified in this release. 



8.21 .4 Shared service control procedures 



Depending on the SSC room policy, one or more UEs may perform room moderation tasks and/or content control. This 
can include adding and removing content to the SSC room. Additionally service commands, such as CoD trick play or 
BC channel changes, can be performed for the shared service in the SSC room. The change in service state following 
from this service command is then reflected towards all other UEs involved in the shared service. The SSC room policy 
can indicate that room moderation and/or floor control is applicable to the shared service. This allows for resolving 
potential command conflicts that may occur due to interactions between service and/or media control commands 
received from different users. 

NOTE: The extent of room moderation and/or floor control can be described by the room policy and may be 
subject to application design. Appendix B includes further details on the various policies and their use. 

If synchronization is needed for shared service control, the procedures in clause 8.15 will be applied and the 
SyncGroupId shall be populated with the SSC room identifier. 

8.21 .4.1 Shared BC channel changes 

Depending on the SSC room policy, when a BC service is shared in an SSC room, the channel changes issued by an UE 
will be reflected towards all others UEs involved in the shared service. The SSC room policy indicates how conflicts in 
case of non-overlapping BC service packages are handled. For example, if all UEs involved in the shared BC service 
have a subscription to the same BC service package(s), no specific handling of conflicts is required. If the BC service 
packages that each UE is subscribed to do not completely overlap, the notification mechanism is employed to indicate 
and/or resolve conflicts at the UE that causes the conflict occurrence due to an issued channel change command. 

Figure 39G depicts the typical steps that occur when one of the UEs involved in the shared BC service issues a BC 
channel change: 
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Figure 39G: Shared BC channel changes 

1) The UE performs broadcast TV channel switching according to clause 8.3.4. 

2) If conflicts arise due to non-overlapping BC service packages of the UEs involved in the shared BC service, 
the UE receives a notification from the SCF to indicate and/or resolve the conflict. Depending on the SSC 
room policy, the notification contains a message to be displayed on the UE screen and/or instructions for the 
UE how to handle the conflict. If multiple UEs are impacted by the conflict, each of these UEs should receive 
a notification. 

NOTE: Indication of the conflict can be implemented e.g. as visual pop-up on the UE screen, asking the user how 
to handle the conflict, or through automatically-handled notifications, that e.g. remove the user from the 
SSC room. The exact service behaviour is subject to implementation choices and can be described in the 
SSC room policy. 

3) If no conflict has occurred, or if conflicts have been resolved, the channel change is reflected towards each UE 
involved in the shared BC service. The notification procedures from clause 8.11. may be employed. 

8.21 .4.2 Shared CoD trick play commands 

Depending on the SSC room policy, when a CoD service is shared in an SSC room, the trick play commands issued by 
an UE will be reflected towards all others UEs involved in the shared service. The SSC room policy indicates how 
conflicts in case of (near-)simultaneously received trick play commands are handled. 

Figure 39H depicts the typical steps that occur when one of the UEs involved in the shared CoD service issues a CoD 
trick play command. 



£75/ 



127 



ETSI TS 182 027 V3.4.1 (2010-06) 






1 . Media Control Request 





SSC Room control 



2a. Room policy Reque; t 



2b. Room policy Response 



3. Indicate conflict 
H 



4. Notification using signalling path (8.11.1) 



5. Media Control Response 



6. Instruction for reflecting media control command 



Figure 39H: Shared CoD trick play commands 

1) The UE issues a media control command, i.e. CoD trick play command, to the serving MF. 

2) If the SSC room policy has not been pushed to the MF during shared service initiation, the MF pulls the room 
policy from the SCF. 

NOTE 1: The pull mechanism for requesting the SSC room policy by the MF from the SCF also allows for 
updating the SSC room policy depending on the service states. 

3) If conflicts arise due to e.g. (near-)simultaneously received trick play commands of the UEs involved in the 
shared CoD service, the MF notifies the SCF. 

4) The UE receives a notification from the SCF to indicate and/or resolve the conflict. Depending on the SSC 
room policy, the notification contains a message to be displayed on the UE screen and/or instructions for the 
UE how to handle the conflict. If multiple UEs are impacted by the conflict, each of these UEs should receive 
a notification. 

NOTE 2: Indication of the conflict can be implemented e.g. as visual pop-up on the UE screen, asking the user how 
to handle the conflict, or through automatically-handled notifications, that e.g. prevent to command being 
executed. The exact service behaviour is subject to implementation choices and can be described in the 
SSC room pohcy. 

5) The MF sends the media control response to the UE. 

6) If no conflicts have occurred, or if conflicts have been resolved, the media control command is reflected 
towards each UE involved in the shared CoD service. The notification procedures from clause 8.11. may be 
employed. 
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8.21 .5 Room deletion procedure for SSC 

Figure 391 depicts the typical steps that occur when the UE deletes an SSC room. 
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Figure 391: SSC Room Deletion procedure 

1) The UE sends a SSC Room Deletion Request through the Core IMS to the SCF. This request may contain 
information such as: 

the SSC Room Identifier of the to-be-deleted SSC room; 

optionally, the service identifier if the room is associated with only one service item; 

and optionally additional information such as list of users that need to be informed of the room deletion. 

2) The SCF checks if the user has the rights to delete the room and records the SSC room information. It sends an 
SSC Room Deletion Response including the SSC room identifier through to core IMS to the UE. 

3) Deletion of published SSC room information is performed by informing the SSF, by triggering the SCF to 
send a notification or recommendation, or by sending a message to appropriate other UEs. 

4) The SCF may optionally notify the users in the list indicated in SSC room deleted request that the room has 
been deleted. 

8.22 Personalized Service Composition (PSC) procedures 
8.22.1 General 

This clause describes procedures for the PSC service where multiple EC and or CoD sessions are composed into a 
single Personalized Service Composition. Existing BC/CoD procedures are used for session setup in order to compose 
the PSC. Additional steps include selection and configuration of the PSC between the UE and SSF, handling of cases 
where there are insufficient resources available for the full PSC and synchronization of the PSC constituting media 
streams. 

NOTE: This clause only applies when multiple EC and/or CoD sessions need to be associated with each other at 
the SCF and/or other functional entities. Initiating multiple not-associated BC/CoD sessions and 
including multiple media streams within a single EC or CoD session are implicitly covered by 
clauses 8.3.1.1 and 8.4.1.1. 
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The following compositions of multicast and unicast media streams are supported: 

• UE receiving multiple multicast streams within multiple BC sessions; 

• UE receiving multiple unicast streams within multiple CoD sessions. 

• UE receiving any combination of multicast and unicast streams within BC and/or CoD sessions. 

8.22.2 PSC session initiation 

Figure 39Ia depicts the typical steps that occur during the establishment of a Personalized Service Composition session 
and its constituting BC/CoD sessions. 
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Figure 391a: Signaling flows for Personalized Service Composition 

1) The UE makes a selection of a Personalized Service Composition (PSC) from the SSF. The PSC, to be 
composed from multiple BC and/or CoD sessions, is either preconfigured in the SSF or configured by the user. 
The UE generates a PSCid that correlates the different BC/CoD sessions in the PSC. 

NOTE 1 : PSC combinations of multiple BC and/or CoD sessions may require more complex EPG data, as 
supported by e.g. OMA BCAST service guide. 

NOTE 2: Users can bookmark a particular PSC combination including its PSCid for future usage. 

2) The UE initiates a PSC session with the SCF. The PSC session initiation request contains the PSCid and the 
IPTV content identifiers of the PSC constituting BC/CoD sessions, see clause I.l. Such content identifiers are 
for example BCServiceld (clause 7.4.1), CoDId (clause 7.4.1), N-PVRContentId (clause 7.4.1), ad content id 
(clause 8.14.1) UGC content id (clause 8.9.2) and/or shared content identifier (see clause 8.21.2). It may also 
contain handling instructions, e.g. instruction for the case that there is insufficient bandwidth to constitute all 
requested BC/CoD sessions simultaneously. 

3) The SCF initiates a BoC or CoD session to the UE, following the procedures of clauses 8.3.1.1.2 or 8.4.1.1.2. 

The session initiation request includes the PSCid which is used by the UE to correlate the incoming BC/CoD 
session initiation request with the PSC session. 

4) The SCF initiates additional BoC and/or CoD sessions to the UE to build the PSC. Step 4) may be repeated 
zero or more times. 
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5) The SCF verifies resources availability. If step 3) and/or one or more of the steps 4) fails due to insufficient 
resources, then the SCF may try and set up an alternative offer that is either preconfigured in the SCF or 
signalled as handling instructions in step 2). Examples of such an alternative offer are downgrading, 
not-initiating or terminating one or more of the PSC constituting BC/CoD sessions, or terminating the PSC 
session as a whole. An example of the downgrading case is described in clause 8.22.3. 

6) The SCF confirms the establishment of the PSC session. 

At this point, the PSC constituting BC/CoD sessions and their associated media streams are available at the UE and they 
can be presented to the user as a composite, e.g. picture-in-picture, replacing an audio stream, etcetera. 

If synchronization is needed between the media streams within the PSC, the procedures in clause 8.15 will be applied. 

Once the PSC session is established, the UE or the SCF may use the PSCid and the associated PSC constituting 
BC/CoD sessions to perform actions on the PSC as a whole, for example adding or removing PSC constituting BC/CoD 
sessions; N-PVR recording the PSC; or terminating the PSC session as a whole. 

NOTE 3: There are many ways that Personalised Service Composition can be combined with other IPTV services. 
Examples of these are N-PVR recording of a PSC; continue viewing a PSC on another device, 
bookmarking of a PSC, shared PSC content; PSC trick play. 

8.22.3 Session modification during PSC session initiation 

The SCF may modify IPTV sessions during the PSC session initiation. Figure 39Ib shows an example of steps that 
could be taken if resource allocation failure occurs during the PSC session set-up. In this example, the resources for a 
BC session are reduced in order to use those resources for the CoD session. The example assumes that the quality of the 
BC session could be scaled back, e.g. by using scalable video or by switching from high definition to standard 
definition. 
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Figure 391b: Example of session modification during PSC session initiation 

1) PSC selection, see clause 8.22.2 step 1. 

2) PSC session initiation, see clause 8.22.2, step 2. 

3) BC session initiation within PSC, see clause 8.22.2, step 3. 
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4) CoD session initiation within PSC, see clause 8.22.2, step 4. In this example, the resource allocation fails. The 
CoD session initiation is halted. 

5) The SCF verifies resources availability, see clause 8.22.2, step 5. In this example, the SCF detects resource 
allocation failure. The SCF tries to set up an alternative offer. In this example, the SCF downgrades the 
previously established BC session using a BC session modification procedure see clause 8.3.2, figure 16. 

4a) The SCF continues the halted CoD session initiation. Because of the resources freed in step 5), this step is 
completed successfully. 

6) The SCF confirms the establishment of the PSC session, see clause 8.22.2, step 6. 

8.22.4 PSC session release 

When the PSC session is no longer needed, it is released by the UE or SCF. 

8.22.4.1 UE-initiated PSC session release 

Figure 39Ic shows the information flow for UE-initiated PSC session release. 
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Figure 391c: UE-initiated PSC session release 

1) The UE sends a PSC session termination request to the SCF. 

2) The SCF terminates the PSC constituting BC/CoD sessions following the procedures of clause 8.3.3 figure 18 
and/or clause 8.4.3, figure 30. 

3) The SCF confirms the PSC session termination to the UE. 

8.22.4.2 SCF-initiated PSC session release 

Figure 39Id shows the information flow for SCF-initated PSC session release. 

NOTE: The system may decide to terminate PSC if all of the constituting IPTV sessions have been terminated. 
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Figure 39ld: SCF-initiated PSC session release 

1) The SCF sends a PSC session termination request to the UE. 
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2) The UE terminates the PSC constituting BC/CoD sessions following the procedures of clause 8.3.3, figure 17 
and/or clause 8.4.3, figure 29. 

3) The UE confirms the PSC session termination to the SCF. 

8.23 Signalling flows for IPTV Content IVIarker service 
procedures 

IPTV Content Marker service procedures consist of two types (see clause 7.5.2). 

• Storing of IPTV Content Marker data: this type of procedure allows a user to store configurable pointers to 
content (entire content or parts of content, e.g. favourite scene) and be able to quickly access that content. 

• Retrieving of IPTV Content Marker data: this type of procedure allows a user to exchange and share IPTV 
favourite data. 

8.23.1 IPTV Content Marker storing procedures 

Figure 39J provides an overview of the information flows for IPTV Content Marker storing. This procedure can occur 
at any time during IPTV services (BC/CoD/N-PVR/etc). 



UE 



(1) IPTV Content Marker Storing 



Request 



Core IMS 



# 



r 5) IPTV Content Marker Storing 
Response 



SCF 



(2) IPTV Content Marker Stori 
Request 



¥ 



(3) IPTV Content Market 



store 



^4) IPTV Content Marker Storing 



Ri 



esponse 



Figure 39J: IPTV Content Marker storing procedure 

1) The UE sends a IPTV Content Marker storing request to save content information. This content information 
may include various information, e.g. the entire/scene of content with/without current watching. 

2) The IMS core forwards this request to the SCF. 

3) The SCF stores the indicated content information as Content Marker data for this user. The data model of 
IPTV Content Marker items is defined in clause 7.5.2. 

4) The SCF confirms storage of IPTV Content Marker data. 

5) The IMS core forwards the response to the UE. 

8.23.2 IPTV Content Marker retrieval procedures 

Figure 39K provides an overview of the information flows for IPTV Content Marker retrieval. This procedure can occur 
at any time and may be used to share IPTV Content Markers. 
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Figure 39K: IPTV Content Marker retrieval procedure 

1) The UE sends a IPTV Content Marker retrieval request. 

NOTE: The IPTV content identifier (clause! 1) or other parameters (e.g. the fields required by the user) may be 
specified in the request to help filtering the IPTV Content Marker data. 

2) The SSF returns IPTV Content Marker retrieval response. The response shall contain the user's IPTV Content 
Markers. If there is any user id in IPTVContentMarkerSourceUser parameter, then the SSF response also 
contains the indicated user's IPTV Content Marker data. If there is any IPTV content identifier or other 
parameters in the request, then the SSF retrieves and responds the indicated IPTV Content Marker data.When 
retrieving that user's IPTV Content Marker data, the SSF shall perform authorization according to that other 
user's IPTVContentMarkerAuthorizedViewUser settings. 

Alteratively, the UE may fetch the IPTV Content Markers from the SCF. In that case the SCF shall generate the IPTV 
Content Marker retrieval response. This response shall contain the user's IPTV Content Markers. If there is any user id 
in IPTVContentMarkerSourceUser parameter, then the SCF response also contains the indicated user's IPTV Content 
Marker data. If there is any IPTV content identifier or other parameters in the request, then the SSF retrieves and 
responds the indicated IPTV Content Marker data. When retrieving that user's IPTV Content Marker data, the SCF shall 
perform authorization according to that other user's IPTVContentMarkerAuthorizedViewUser settings. 

8.23.3 IPTV Content Marker update/removal procedures 

Figure 39L provides an overview of the information flows for IPTV Content Marker update/deletion. 



UE 



(I) IPTV Content Marker Update 



Request 



Core IMS 



( 5) IPTV Content Marker Update 
Response 



SCF 



(2) IPTV Content Marker Updal ^ 
Request 



(3) IPTV Content marker 
update/removal 



^4) IPTV Content Marker Update 



Ri 



esponse 



Figure 39L: IPTV Content Marker update/removal procedure 
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1) The UE sends a IPTV Content Marker Update request to update/remove content marker data. In case of 
update, the request includes the IPTVContentMarkerlD and updated parameters. In case of removal, the 
request can include a specific IPTVContentMarkerlD or no IPTVContentMarkerlD. The latter means that all 
content markers shall be removed. 

2) The IMS core forwards this request to the SCF. 

3) The SCF updates or removes the indicated Content Markers for this user. In case of update, the parameters that 
are not indicated in the request shall not be changed. 

4) The SCF confirms update/removal of IPTV Content Marker data. 

5) The IMS core forwards the response to the UE. 

8.24 Roleof BGFin IPTV 

In certain IPTV scenarios there is a need to bypass the BGF for scalability reasons. For example, the BGF could be 
bypassed when using MPEG2-TS directly over UDP transport, as well as, for RTP(RTCP) transmission when there is 
no RTCP towards the network. 

It shall be possible to bypass the BGF. Its use is a local decision taken by the network provider during the IPTV session 
setup based on the session information provided. 

8.25 Procedures for service initiation by remote UE 

The service initiation by remote UE can be used by one remote UE to activate the target UE to start-up the IPTV 
service, for example, it can be used to remote start-up UGC, CoD or BC services. Figure 39M depicts the typical steps 
for service initiated by Remote UE. 
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Figure 39M: Service initiation by Remote UE 

1 A) The Remote UE sends a remote service start-up request through the Core IMS to the SCF. The request carries 
the necessary parameters indicating the service identified by the IPTV service type identifier (see clause 1.2), 
e.g. BC service or UGC service, IPTV content identifier (see clause I.l) when appropriate, user identifier of 
Target UE which start-up the service and user identifier of the remote UE. 

IB) The SCF performs service authorization as described in clause 5. 1, if the Remote UE is allowed to perform 
remote start-up operation of the service, the SCF forwards the remote service start-up request through the core 
IMS to the Target UE. And the user of Target UE may deny the request even if the SCF authorized. 

NOTE 1 : The SCF authorizes the remote UE by checking the user profile of the Target UE. 

IC) The Target UE sends a remote service start-up response through the Core IMS to the SCF. 

ID) The SCF forwards remote service start-up response through the Core IMS to the Remote UE. 

NOTE 2: The remote service start-up request in steps 1 A-ID may directly sent to the target UE if SCF does not 
need to perform authorization. 

2) The Target UE initiates the service indicated in the remote start-up request, e.g. BC or CoD session initiation 
following the procedures of clauses 8.3.1.1 or 8.4. 1 . 1 . 
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8.26 Signalling flows for IPTV service state data 
updates/requests 

IPTV service state data may be updated by MF as described in clause 8.26.1. Furthermore, IPTV service state data 
requests may be initiated by the SCF as described in clause 8.26.2. The procedures are limited to data within the SSD 
model and which the SCF cannot derive directly from ongoing traffic and events. 

8.26.1 IPTV service state data updated by IVIF 

The procedure described in figure 39N is used to update IPTV service state data by the MF. The SSD may need to be 
updated for example when a user pauses a streaming or terminates the session. 



Core IMS 
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(1) SSD update 



(2) SSD update 

► 



(5) SSD update Response 



Request 



nrr_._._, 

Event 
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Figure 39N: IPTV service state data updated by lUlF 

MF is triggered by an event, e.g. by detecting a pause or and end of a session and decides to send changes of SSD to the 
SCF. 

1) MF sends an SSD update request to save the current SSD. This request may also include a indicator to inform 
the SCF of the reason for the SSD update. 

2) The IMS core forwards this request to the SCF. 

3) The SCF updates the SSD. 

4) The SCF confirms the SSD update. 

5) The IMS core forwards the response to the MF. 

8.26.2 IPTV service state data update requested by the SCF 

This procedure allows the SCF to acquire an update of the current service state from the MF during an ongoing session. 

Figure 390 provides an overview of the information flow for an SSD update request by the SCF. This procedure can 
occur at any time during ongoing IPTV services (CoD/N-PVR/etc). 
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Figure 390: SCF IPTV service state data Request Procedure 

1) The SCF sends an SSD request to the MF, via the IMS core, to request the service state during an ongoing 
IPTV service. 

2) The IMS core forwards this request to the appropriate MF for the IPTV service. 

3) The MF acquires the requested information. 

4) The MF returns to core IMS the requested information in an SSD response. 

5) The IMS core forwards the response to the SCF, which updates the SSD accordingly. 

9 Interactions between IPTV services and other 

TISPAN services 

Several approaches can be employed for realizing the interaction between IPTV services and other TISPAN services. 
This clause describes approaches that are considered within the TISPAN architecture, e.g. where application servers 
interact directly through Core IMS. Two other approaches involving 3GPP SCIM and OSA/Parlay methods are 
described in annex C. 



9.1 



Presence and IPTV 



IPTV services may be combined with the presence service capability. This clause describes the mechanisms that apply 
when IPTV services are combined with the presence service capability. 

These mechanisms may also be used for other purposes then publishing user presence information. For example they 
may be used to gather statistics about BC TV Service or user behaviour information. 

9.1 .1 Presence architecture and functional description 

The architecture and functional description of the presence service capability when used in relation to the IPTV services 
conform to TS 182 008 [10]. 
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9.1.2 Presence attributes for I PTV 

The Presence attributes defined in TS 182 008 [10] apply. 

In addition, the following specific IPTV attributes shall be supported: 

• BC service activated; 

• CoD service activated; 

• PVR service activated. 

If the IPTV presence attribute "channel currently accessed" is supported, then the machine-readable part of the 
identification of the channel shall be globally unique. The term globally unique here means that there is no ambiguity in 
the identification of the channel if presentity and watcher (for terminology, see in TS 182 008 [10]) are with different 
network operators and/or in different countries. 

The following specific IPTV attributes may also be supported: 

• IPTV service activated; 

• IPTV service type identifier (see clause 1.2) should be used to identify which service(s) are activated: 

UGC service activated; 
PCoD service activated; 
TAI service activated; 
PCh service activated; 
SSC service activated; 
PSC service activated. 

• IPTV content identifier (see Annex I.l) should be used to identify which content(s) are currently 
accessed/watched: 

BC TV Service currently accessed; 

programme currently watched, when available; 

content currently accessed. 

• current service state (e.g. paused, playing, in trick play mode). 

• IPTV service access history. 

It is up to user's decision to include specific IPTV attributes in presence document. 

Note that if a service relies on user's presence information, but the user has decided not to publish this information, the 
user may not be able to utilize the service. 

When the "BC service activated" attribute is included in a presence document, the attributes "BC TV Service currently 
accessed" and "programme currently watched" may also be included, depending on user preferences. These attributes 
shall not be present in a document if the "BC service activated" attribute is not present. 

When the "CoD service activated" or the "PVR service activated" attribute is included in a presence document, the 
attribute "content currently accessed" may also be included depending on user preferences. This attribute shall not be 
present if the "CoD service activated" or the "PVR service activated attribute" is not present. 
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9.1 .3 SIP related procedure 

The SIP related procedures defined in ES 283 030 [13] apply. 
The publication of CoD related presence information happens: 

• after completion of CoD session initiation procedure; 

• after completion of CoD session termination procedure. 
The publication of BC related presence information happens: 

• after completion of BC session initiation procedure; 

• after completion of the BC session termination procedure; 

• optionally, when the UE successfully subscribes to a particular multicast channel (i.e. channel hopping). 

In order to cope with overload possibly caused by numerous channel-hopping, it shall be possible to define a timer to 
limit the number of publications. This timer is started and reinitialised after each channel change. Publication shall only 
be sent when the timer elapses. 

NOTE: Preventing overload caused by numerous IPTV service access entries, is possible by defining a timer or 
ceiling to limit the number of publications. 

The publication of UGC related presence information happens: 

• after completion of UGC creation session initiation procedure; 

• after completion of UGC creation session termination procedure; 

• after completion of UGC watching session initiation procedure; 

• after completion of UGC watching session termination procedure. 
The publication of PCoD related presence information happens: 

• after completion of PCoD session initiation procedure; 

• after completion of PCoD session termination procedure. 
The publication of PCh related presence information happens: 

• after completion of PCh session initiation procedure; 

• after completion of PCh session termination procedure. 
The publication of TAI related presence information happens: 

• after completion of TAI session initiation procedure; 

• after completion of TAI session termination procedure. 



9.2 Incoming call management 



The combination of basic IPTV services (e.g. Broadcast, CoD and N-PVR) with telephony allows a user to have 
increased control over incoming calls when watching TV. 

This clause describes an approach, where the IPTV SCF decides based on incoming call state, IPTV service state and 
user profile settings how to handle the call. Approaches using only standard IMS telephony mechanisms to inform 
IPTV UE of incoming calls are described in [2]. 

Also, if the user is registered with the same IMPU on the UE (Phone) and UE (IPTV ) normal IMS forking procedures 
(as described in [2], clause 4.2.7) apply. The following procedure only applies if the user is registered with different 
IMPUs on the aforementioned UEs or when forking results in the IPTV SCF being involved. 
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9.2.1 Procedure for incoming call management 

Figure 39P shows a signalling flows for incoming call management. 
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Figure 39P: Signalling flows for incoming call management 

NOTE 1: "Incoming call" indicates an incoming call that may come from different sources such as a telephony AS, 
an originating network, or a UE. 

1) An incoming call is received by the Core IMS. 

2) The Core IMS forwards the session initiation request to SCF. 

3) The SCF retrieves user profiles and IPTV service and call state. 

4) Optionally, the SCF notifies the user and ask what to do with the incoming call, based on IPTV service and 
call state, if this is indicated in the user profile (see clause 9.2.2). In case of no answer from the user on the 
IPTV UE Bl after a timeout, SCF may perform any of the actions in step 5. 

5) Optionally, the SCF performs one or more actions. For example, these actions are performed based on 

the IPTV service and call state; 

and/or the answer of the user if step 4 is performed and an answer from the UE has been received by the 
SCF; 

and/or indications in the user profile (e.g. pause on incoming call using network-controlled trick play 
from clause 8.16 or redirect the call to voicemail). 

6) Telephony session establishment: based on the outcome of the previous steps the SCF handles the incoming 
call (e.g. accept, reject the call or forward to another AS). 
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7) Optionally, the SCF notifies the user on its UE Bl (IPTV ) about the incoming call (e.g. "caller id" 

presentation on the TV) and/or optionally, about the action that has been performed during step 4 on behalf of 
the user. 

NOTE 2: The order of the steps 4-7 may change. Steps 4, 5 and 7 are optional. For example, an incoming call 

notification that requires user action is covered on step 4; an incoming call notification that only present 
the incoming call (e.g. "caller id") is covered by step 7. 



9.2.2 Incoming call accepted on a phone device 

Figure 39Q shows a signalling flow for an incoming call accepted by user. 
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Figure 39Q: Signalling flows for an incoming call accepted by user 

1) The SCF sends a notification to UE Bl (IPTV) with a message about incoming call from user A (using 
notification procedures using signalling path as described in clause 8.11.1.1). 

2) User B may select from multiple options how to handle incoming call, for example: 

Accept on TV; the TV signal is paused and phone is ringing. 
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Accept on phone; the call is forwarded to user B's UE B2 (Phone). According to his user profile and 
service and call states, the TV can either be paused or can continue. 

Route to mailbox; if user B does not answer the call or based on his user profile, the call is forwarded to 
his voicemail box. 

Refuse; user B does not answer the call. 

3) Based on the user decision in step 2, UE Bl (IPTV) sends to SCF response how to handle the incoming call 

4) - 5) The SCF forwards the session initiation request to UE B2 (Phone) via Core IMS in B2BUA mode (The SCF 

stays in the call path). 

6) - 7) UE B2 (Phone) sends a session initiation response to the originating network via the SCF (in B2BUA mode). 
8) - 9) SCF sends the session initiation response to the originating network via the Core IMS. 
10) Telephone session established. 

9.3 Message and IPTV 
9.3.1 Messaging procedures 

Messaging procedure is used for several purposes: where messages are sent between users or between system and users. 
Following procedures may be primarily used for immediate messaging described in TS 181 016 [15] in section in 
clause 6.2.3 to provide services specified in TS 122 340 [16] together with IPTV services. Several additional specific 
use cases described in TS 181 016 [15] (e.g. in clause in annex A) require integration of existing messaging systems (in 
this case IMS based messaging) with IPTV service logic to provide blended IPTV and messaging service 
(e.g. messaging during BC service or chat discussion related to content or related to used IPTV service, etc.). 

Figure 40 depicts the typical steps that occur when the UE wants to send message from one user to one or more other 
users using signalling path. 
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Figure 40: messaging procedure using signalling path 

1) UE sends a message request via IMS core to SCF using signalling path for IMS messaging mechanisms [2]. 
Message contains message itself (supporting different media content types as in [16]) and also parameters 
which identify related IPTV service blended with this messaging procedure. 
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2) SCF evaluates appropriate destination UEs for delivery message to specified group of users (as users 
interaction related with IPTV services) based on service logic (and other conditions e.g. user profile or 
messaging rules) specified for required IPTV service. SCF may also modify/generate messages (original 
message may be included together with additional IPTV related information e.g. watched channel, form of 
presentation of message, etc.). 

3) SCF sends message (original/modified) via IMS core using IMS messaging framework [2] to one or more 
UEs. 

NOTE : In this example the messaging service function is not explicitly shown for brevity. IMS messages may 
traverse the messaging service function, and are under service provider control. Furthermore, while 
figure 40 shows the SCF in the path of the IMS message, this is an option and need not be the case for all 
IMS messages originating/terminating from/to an IPTV end user. The SCF would typically be in the 
signaling path of an IMS message if the message is addressed explicitly to it, or if it has to perform some 
special procedure on the message. 

9.3.2 Procedures for deliver messages of BC service using media patii 

This clause describes mechanisms of deliver messages that are associated with a BC service using media path. 

These mechanisms may be used for some purposes. For example they may be used to participate in a comment service 
associated with a BC program; one user can send his comment to the SCF using IMS immediate message services, then 
the SCF and the MF deliver the comments to all users who subscribed to the comment service associated with the BC 
service. 

Figure 41 depicts the typical steps that occur when one user sends IMS immediate messages to SCF, and SCF and MF 
deliver the message to users who subscribed to the message services associated with the BC service. 

NOTE 1: The parameters for joining the multicast group, i.e. multicast address, need to be available to UE 
before it receives the messages delivered using media path. 
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Figure 41 : Deliver messages of BC service using media path 

1) UE joins a BC service and the messages multicast group associated with the BC service, e.g. comment services 
of a BC service. 

2) UE initiates an IMS immediate message request carrying the message, which is specified in the IMS stage 2 
specification [2]. The immediate message is routed by Core IMS to the SCF in charge of the delivery of 
messages associated with the BC service. 
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3) The SCF detects which BC service is associated with the IMS immediate message e.g. by the destination of the 
immediate message, and sends the IMS immediate message to the selected MF. The MP transfers the IMS 
immediate message to the multicast group associated with the BC service. The procedures use mechanisms of 
delivering notification using media path specified in clause 8. 1 1 . 1 .2, and the notification request from SCF to 
the selected MF at least contains parameters of BC service ID and the message. 

NOTE 2: Existing mechanisms of IMS could be used for the SCF to distinguish IMS immediate message from 
normal IMS message, e.g. by checking the content type of the message body. 

9.4 Event Handling involving the SCF 

Event handling by the SCF takes place if the SCF receives events from several sources. The events can include requests 
from the UE, new content arrival notification, presence updates, trick play reports from MF, channel change reports 
from UE, events from other NGN application servers, external applications and so on. Usage of this procedure occurs in 
several cases under clause 8. SCF involvement is required depending on the event and the user profile configuration. 
Examples include incoming call management involving multiple UE's (e.g. pause on incoming call), emergency 
warning and alerting systems, or parental control. In such cases the SCF needs to correlate the event with the right UE 
and apply service logic to determine the applicable action to the UE and/or MF. 
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Figure 42: Event handling involving the SCF 

1) The SCF receives an incoming event which requires handling. 

NOTE 1 : It is up to the IPTV Service Provider, on behalf of the user and/or based on the service requirements, to 
decide when to route an incoming event to the SCF a or send it directly to the UE. 

2) The SCF correlates the incoming event with the designated user/group of users and/or UE's, performs 
authentication and detects the ongoing IPTV service status. Detection of the IPTV service status is done based 
on IPTV Service Action Data or using IPTV Presence information. 

NOTE 2: The SCF can decide which (if any) further actions to perform, e.g. based on user preferences and detected 

service state. 

3) The SCF performs an action towards the UE and or MF, e.g. it can send a notification to the UE or instruct the 
UE to send a trick play command/change the channel. 
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10 Security 



10.1 Authentication 

Authentication procedures for the Ut reference point conforms to TS 187 003 [5]. 

10.2 Content Protection 

The locations and related reference points of the following elementary functions are defined in TS 187 003 [5]. They 
are reproduced below for information. 

For content protection the following elementary functions are used: 

• Content licensing: This elementary function handles the licenses issuing related functions, including 
generation and distribution of the licenses to the desired entities. 

• Key management: This elementary function handles the management of the security keys on behalf of the 
content usage profiles as defined in the content licencing, including generate and provide the keys and 
corresponding parameters to the desired entities. 

• Content encryption: This elementary function handles the content protection related operations, e.g. content 
encryption and encapsulation operations, etc. 

These three elementary functions may be flexibly located in existing functional entities or new ones as a whole or in 
independent parts. 

NOTE: Some of these elementary functions may be executed on-line (in real-time) or off-line (in this case could 
be part of the management). 

10.3 Service Protection 

The locations and related reference points of the following sets of elementary functions are defined in TS 187 003 [5]. 
The function groups are reproduced below for information. 

The service membership (SMF), service key management (SKMF) and service protection (SPF) functions described in 
this clause each involve a set of elementary functions required as part of a generic model for service protection. The 
SMF, SKMF, and SPF do not duplicate, but collaborate and interact with existing elementary functions in order to 
perform service protection. 

For service protection the following sets of elementary functions are used: 

• Service membership elementary functions (SMF): This set of elementary functions handles the granting and 
revoking of service access rights to access the IPTV services. Metadata related to the service rights 
management are maintained by the SMF. 

NOTE 1 : The SMF is handled in an array of existing elementary functions (e.g. service key triggering function) and 
functional entities. For example, service authorization may be provided by the SCF, and meta-data is 
maintained in the UPSF. 

• Service key management function (SKMF): This set of elementary functions acts on behalf of the Service 
Membership Function and as such manages service security keys, including generating and providing keys and 
corresponding parameters to the desired entities. 

• Service protection function (SPF): This (set of elementary) function(s) handles the service protection related 
options, e.g. service confidentiality, integrity operations and authorization at the service access point, etc, 
using the keys generated in SKMF. 

NOTE 2: The SPF includes group association, e.g. multicast group. 
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1 1 Charging 

IMS charging principles apply as defined in ES 282 010 [i.3]. 

TISPAN IMS -based IPTV shall use the generic IMS charging model using the standardized Rf reference point for 
offline- and Ro reference point for online charging. 

NOTE: Further IPTV service-specific charging may be required in addition to the generic IMS charging but is out 
of scope for the present document in this release. 



12 Management 

12.1 Management requirements 

For each IPTV service, several entities require to be provisioned with necessary network parameters (e.g. multicast 
addresses for multicast services, source of original content, etc.) and to associate specific content or service with these 
network parameters. These entities are: 

• the SSF, as it needs to provide the UE with the content identifier associated to an IPTV service and possibly 
with a set of network parameters (control and/or content channel descriptions) necessary to initiate an IPTV 
session; 

• the MFs, as they need to associate a content identifier with multicast or unicast streams to be delivered to the 

UE; 

• the SCF, as it may also need to provide the UE with network parameters in response to service initiation 
requests, in configurations where the SSF does not provide this information beforehand. 

Consistent information has to be provisioned on these entities. 



12.2 Content management 



Content management functionalities are responsible for managing acquisition of content and service information 
(e.g. metadata) from content and its metadata sources of content provider, controlling validation and/or 
processing/adaptation to the required format and also to provide management functionalities for supporting distribution 
of the prepared content to the media delivery function and distribution of content among different media delivery 
functions. 

NOTE: Content management is used in the case of offline or online ingest of the content. The online ingest means 
receiving content directly streamed from the content provider. The offline ingest refers to content files 
delivered by other means than the online (e.g. such on physical media like DVD, CD, etc.). The content 
management is used by the IPTV service provider to statically provision the content. 

Content management functionalities can consist of the following groups of elementary functions: 

• Content acquisition - responsible for content management functionalities needed to acquire, aggregate and 
import content/metadata from multiple external sources of content providers. 

• Content validation/adaptation - after acquisition it could be necessary to manage content/metadata format 
validation and verification as well as to define a relation between content and its metadata. Management can 
also control media or metadata adaptation and/or processing (e.g. transcoding, packaging, scheduling, 
resolution conversion, editing, etc.) to the required type of media files or streams. 
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Content distribution Control - management functionalities for control the distribution of content and its 
metadata from content providers when content acquisition/ content validation/adaptation were performed to 
appropriate functional entity (e.g. media files storage in MDF). This function handles the whole lifecycle of 
the content and provide management support for its distribution to media delivery distributed architecture (e.g. 
uploads on video streamers, moving according to management criteria such as popularity, regionalization, 
un-referenced content, MDF resources and so on). Additionally, this function can control the content 
distribution among MDFs (e.g. delete content in some MDFs, moving content from one MDF to other MDFs) 
according to some criteria such as content popularity. 



1 3 Support of Metadata 

13.1 Introduction 

IPTV Metadata enriches the service experience of the IPTV Services a user has access to. IPTV Metadata may originate 
from the User, the NGN Service Provider, the Application Provider or the Content Provider. The Metadata should be 
processed, filtered and enriched by involved IPTV solution entities in order to improve the user experience. 

NOTE 1 : Processing, Filtering and Enriching Metadata may be based on techniques like personal preferences, 
additional subscribed-to services and other means and are out of scope of the present document. 

NOTE 2: How user originated Metadata is injected into the IPTV solution is out of scope of the present document. 

NOTE 3: Content metadata may be delivered along with the content in real time (from MDF). In this case metadata 
might differ from the metadata already stored in the SSF and therefore SSF can require update them with 
relevant metadata from MDF. Also, IPTV CRS might be a service requiring the SCF to access actualised 
metadata. Generally, if UE or other entity needed most updated metadata it is requesting them from SSF 
(SSF is responsible acquire most updated metadata). 

NOTE 4: The mechanisms and handling of all possible cases for synchronization of metadata cross multiple IPTV 
Fes, are not provided in the current specification. 

The access to Metadata may be considered as a service in itself which shall be protected by appropriate service 
authorization means before the Metadata is delivered to the UE. 

13.2 SSF support 

IPTV Metadata may be delivered outside of an IPTV service session by the SSF. 
Xa shall be used for the Metadata delivery. 



13.3 SCF/MF support 



IPTV Metadata may be delivered as part of a normal IPTV service session or inside an IPTV service session dedicated 
to Metadata delivery. In the first case, the Metadata is sent in addition to Media as part of the IPTV session. In either 
case the Metadata capabilities are negotiated during session setup or session modification between UE and SCF. The 
Metadata itself is delivered via the MDF through unicast or multicast via Xd. 
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1 4 Support of Mobility Capabilities 

To support the mobility capabilities of IPTV services, the UE shall support roaming in the Visited Network. When the 
UE is located in the Visited Network, it can access the IPTV services in its own home network. Sometimes when the 
IPTV Service Provider servers both home network and visited network, the MF can server both visited network and 
home network. Annex H give interconnection examples to support of mobility capabilities. 



15 Emergency alert 



The IPTV solution shall enable deliver emergency alerting based on different aspects (e.g. type of emergency situation, 
priority, and locality). TISPAN IMS based IPTV subsystems may in practice also require secure mechanisms to acquire, 
verify and inject the appropriate content (alert message or emergency live transmission) after ensuring that it comes 
from an authorized source. The emergency alerts will only achieve their purpose if they are immediately delivered to 
UE (interruption of actually watched content may be required) when they alert the public promptly, accurately and 
efficiently and then correctly decoded and rendered on the user equipment. 

Following examples of procedures may be used for delivery of emergency alert to UE (other existing delivery 
mechanisms are also possible): 

• using notification procedures to deliver message (notification procedures as in clause 8.1 1.1.1) with 
confirmation of delivery. 

• using notification procedures using multicast media path as described in clause 8. 11 . 1 .2 (for stream insertion 
or replacement of actually watched content) or to deliver live emergency transmission via multicast (e.g. using 
SCF-initiated BC session initiation). 

NOTE: Emergency alert capability can be subject to local or regional regulation. 
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Annex A (informative): 

Integration of non-SIP-AS Service Discovery Function in 

IIVIS based IPTV 



A.1 Introduction 



Clause 5 defines Service Discovery and Selection (SD and S) as a two step process consisting of Service Discovery and 
Service Selection. While clause 5 focuses on discovering services by an SIP based SDF entity, the Service Selection 
uses non-SIP mechanisms. This annex describes using non-SIP SDF to reuse standard non-SIP Service Discovery 
technologies such as DVB-IP Service Discovery as specified in TS 102 034 [6]. 



A.2 Architecture 
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Figure A.1 : Functional architecture for IPTV services integrating non-SIP SDF 



A.2.1 Functional entities 

Figure A.1 depicts the IMS based IPTV architecture based on figure A.2 using a non-SIP AS SDF for Service 
Discovery. All entities are defined in clause 5. 
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A.2.2 Reference points 



Figure A.l depicts the IMS based IPTV architecture based on figure A.2 using a non-SIP AS SDF for Service 
Discovery. All shown reference points are defined in clause 6 except Xa' which is described in the following clause. 



A.2.2.1 UE-SDF(Xa') 

This reference point delivers Service Discovery Information, i.e. SSF addresses in the form of URIs and/or ip-address, 
from the SDF to the UE. Both Unicast and Multicast delivery of this information is possible. 

The use of Xa' conforms to TS 102 034 [6] clause 5.2.5, where the term "HNED" is to be replaced by "UE" and where 
"Location(s)" carries the SSF address(es). 

A.2.3 Procedures 

A.2. 3.1 IPTV service attacinment and selection 

Figure A.2 defines steps 3 and 4 of figure 9 in case the SDF is not SIP- AS based. 



UE 



SDF 



(1) attachToIPTV 



SSF 



(2) SSF Election 



(3) Service Config Info ( Elected SSF address,...) 



(4) request selection data 



(5) retrieve selection data (EPG, CoD catalog, ...) 



Figure A.2: IPTV service attachiment and selection 

1) The UE requests the SDF it was assigned. This assignment may have occurred during the network attachment 
phase, during offline provisioning or by other means. 

2) The SDF determines the proper SSF (or SSFs). It is for further study how the SDF may take into account the 
UE's capabilities, the user's profile and/or the location of the UE (Personalized Service Discovery). 

3) Configuration information that includes the SSF address(es) is (are) routed back to the UE. 

4) The UE requests the SSF to get the selection data. 

5) The SSF delivers the requested data to the UE. 

NOTE: If a non-SIP AS SDF is used for IPTV service attachment, no IMS registration prior to step 1) of 

figure A.2 is required. Therefore, step 2 of figure 9 (IMS registration) can occur in parallel to, before or 
after the procedure described in figure A.2. 
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Annex B (normative): 

Policies for Shared Service Control 

B.1 SSC room policies 

An SSC Policy is associated with an SSC room, identified by the Roomid attribute. A user in an SSC room has an SSC 
Privilege containing the allowed actions by that user. Additionally, SSC room privileges can be allocated to service 
logic for performing room administration tasks. 

Note that this annex does not describe an SSC room data model, nor does it describe implementation of the SSC room 
itself. 

Figure B.l shows a generic data model for an SSC Policy. 



sec User 



■UserlD 



0..* 



SSC Policy 



■RoomID : string 



-> 



SSC Privilege 



^^ 



1 1 



RoomAdministration 



-AddUser : boo! 
-NotifyUser : bool 
-InitiateService : bool 
-RemoveService : bool 
-DeleteRoom : bool 
-GiveFloor : bool 
-TakeFloor : bool 
-SendMessage : bool 
-IsAdmin : bool 
-Islnitiator : bool 
-ArbitrateConflict : bool 



ContentControl 



-AddContent 
-ChangeContent 
-RemoveContent 
-BlockContent 



TrickplayControl 



■PlayContent 

■PauseContent 

■RewindContent 

■RestartContent 

■FastForwardContent 

■StopContent 



Figure B.1 : Data model for SSC Policy 

Room Administration actions: 

AddUser: boolean indicating whether the user is allowed to add other users to the SSC room. Adding 
users to the room is done by extending the list of allowed users associated to the room, that is exchanged 
during SSC room creation (step lA of clause 8.21.2). 

NotifyUser: boolean indicating whether the user is allowed to send notifications to other users of the SSC 
room. If a user is allowed to send notifications related to the SSC room, the messaging procedures from 
clause 8.11 apply. 

InitiateRoom: boolean indicating whether the user is allowed to initiate a service in the SSC room 
(clause 8.21.3, step 3). If the SSC room has been created by another user, this user may or may not be 
allowed to do that. 
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DeleteRoom: boolean indicating whether the user is allowed to delete the SSC room. SSC room deletion 
is performed according to clause 8.21.5. 

GiveFloor: boolean indicating whether the user is allowed to give the floor to another user in the room. 
Typically, a chairman has this right. Specific procedures for floor control are out of scope of this release. 

TakeFloor: boolean indicating whether the user is allowed to take floor control. Typically, a presenter 
has this right. Specific procedures for floor control are out of scope of this release. 

SendMessage: boolean indicating whether the user is allowed to send messages to other users of the SSC 
room. If a user is allowed to send messages related to the SSC room, the messaging procedures from 
clause 9.3. apply. 

IsAdmin: boolean indicating whether the user has administrator rights. 

Islnitiator: boolean indicating whether the user has initiated this SSC room, and has associated rights. 

ArbitrateConflict: boolean indicating whether the user has right to arbitrate a conflict. An example of 
such conflict is different users wanting to watch different BC channels. 

NOTE: Different approaches for the arbitration of conflicts exist, but are not describing further here. 

• ContentControl actions: 

Describes actions that can be performed in relation to content services. In case of a shared BC service, the 
content is a channel. In case of a shared CoD service, the content is a CoD item and so on: 

AddContent: boolean indicating whether the user is allowed to add the content to the SSC room. 

ChangeContent: boolean indicating whether the user is allowed to change the content being watched in 
the SSC room. 

RemoveContent: boolean indicating whether the user is allowed to remove content from the SSC room. 

BlockContent: boolean indicating whether the user is allowed to block content from being watched in the 
SSC room. Parental control may be a reason to block content. 

TrickplayControl: 

■ PlayContent: boolean indicating whether the user is allowed to play content. 

■ PauseContent: boolean indicating whether the user is allowed to pause content. 

■ RewindContent: boolean indicating whether the user is allowed to rewind content. 

■ RestartContent: boolean indicating whether the user is allowed to restart content. 

■ FastForwardContent: boolean indicating whether the user is allowed to fast forward content. 

■ StopContent: boolean indicating whether the user is allowed to stop content in the SSC room. 

The SSC policy, or part of it, may be performed at the UE or at the MF. This would prevent the user from sending 
administration and/or content control actions that are is not allowed to. Policy distribution towards the UE is not 
described in the present document. 

Tight floor control follows strict rules on the actions that users may perform in relation to the service state of the SSC 
room. This may require a more detailed floor control policy that sets those rules. It could describe the use of timers and 
master allocation through e.g. tokens. Such policy is not described in the present document. 

Loose floor control allows any user to perform administration and/or content control actions without first taking the 
floor. This can result in control conflicts. An example is when two users are simultaneously trying to switch to different 
BC channels. Such conflicts should be automatically resolved by the network, so that the service state of the SSC room 
and the associated UE's remain aligned. 
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Annex C (informative): 

Architectures for Interactions between IPTV services and 

other TISPAN services 

This Annex contains examples of architectures that can enable the interaction between IPTV services and other 
TISPAN services. The examples of architectures given refer to existing work and serve to clarify how service 
interaction can achieved by using this existing work. For these architectures, it is assumed that service interaction 
requires a dedicated Application Server that may explicitly implement the blended service functionality (e.g. pausing 
the TV on incoming call, or watching apart together). Such an AS can be seen as an external application with respect to 
the TISPAN IPTV architecture. 



C.1 Interaction based on an OSA/Parlay/Parlay X SCS 

This approach is based an OSA/Parlay/Parlay X Service Capability Server (SCS), that provisions standardized 
interfaces and APIs to external and third party application servers. The use of such an SCS is described in 
ES 204 915 [i.5], ES 202 504 [i.6], TS 129 198 [i.7] and TS 129 199 [i.l9]. 

C. 1 . 1 Service Capability Server (SCS) 

The OSA SCS acts as a secure gateway between the underlying network and the application with the OSA architecture. 
It is responsible for providing specific service abilities to third party applications. An SCS further serves to make an 
abstraction of the functionality offered by the network, in effect offering the service capability features of the 
underlying network to the third party applications. 

C.1.2 Architecture 

Figure C.l shows a simplified version of the IMS-based IPTV architecture from figure 2 in clause 5.1.1, with interfaces 
to an SCS and subsequent external applications. 
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External Applications (OSA AS) 

OSAParlayAPI 

OSA/Parlay/Parlay X Gateway (SCS) 



e.g. C ORBA/SOAP 



ISC 



Core IMS 



y2 



e4 




Iransport Processing hunctions 



IPTV 
MF 



IPTV 
MCF 



Xp 



IPTV 
MDF 



Figure C.1 : Interaction between TISPAN llVIS-based IPTV architecture and 
an OSA/Parlay/Parlay X SCS 



C.2 Interaction based on a 3GPP SCIM 

This approach is based on a Service Capability Interaction Manager (SCIM), that allows for service association and 
dynamic service triggering. The use of such an SCIM is described in TS 123 002 [i.8], TS 123 218 [i.9] and 
3GPP TR 23.810 [i.lO]. 

C.2.1 Service Capability Interaction Manager (SCIM) 

The Service Capability Interaction Manager (SCIM)is a function that manages the interaction between IPTV services 
and other NGN services, by e.g. associating the IPTV services with other NGN services and dynamic triggering the 
services in the ongoing session based on the information about the relational session or user's status. 

0.2.2 Architecture 

Figure C.2 shows a simplified version of the IMS-based IPTV architecture from figure 2 in clause 5.1.1, with interfaces 
to an SCIM and subsequent external applications. 
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Figure C.2: Interaction between TISPAN ilUIS-based IPTV architecture and a 3GPP SCIM 
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Annex D (informative): 
Mapping of elementary functions 

D.1 IVIapping of elementary functions to generic 
capabilities 

Mapping of elementary functions in table D.l show which elementary function (listed in clause 5.1.4) are applicable to 
generic capabilities (described in clause 5.1.3A). 

Table D.1 : Mapping of elementary functions to generic capabilities 





Elementary 
function 


Discover 

and 

select 

content 


Service 
control 


Service 
interact 


Media 
control 


Deliver 
media 


Content 
protection 


Content 

mng. and 

distribution 


Service 
Protection 


Service 
interaction 


1 


network attachment 




X 
















2 


registration 




X 
















3 


resource 
management 




X 
















4 


charging 
information 




X 












X 




5 


service discovery 


X 


















6 


service 
authorization 




X 


X 










X 




7 


service selection 


X 














X 


X 


8 


service initiation 




X 


X 














9 


service control 




X 


X 












X 


10 


service information 
handling 


X 


X 


X 












X 


11 


service 
configuration 




X 
















12 


session initiation 




X 


X 










X 




13 


session modification 




X 


X 










X 




14 


session termination 




X 


X 










X 




15 


multicast based 
media delivery 










X 










16 


unicast based 
media delivery 










X 










17 


content 
download/upload 










X 










18 


control of multicast 
streaming 




X 




X 












19 


control of unicast 
streaming 






X 


X 












20 


control of download/ 
upload 




















21 


content 
ingestion/receiving 










X 




X 






22 


content recording 








X 












23 


content storage 








X 












24 


content adaptation 










X 










25 


content acquisition 














X 






26 


content validation 














X 






27 


content distribution 














X 






28 


content licencing 












X 








29 


key management 












X 




X 




30 


content encryption 












X 








31 


user profile/data 
mng. 
















X 


X 
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Elementary 
function 


Discover 

and 

select 

content 


Service 
control 


Service 
interact 


Media 
control 


Deliver 
media 


Content 
protection 


Content 

mng. and 

distribution 


Service 
Protection 


Service 
interaction 


32 


accounting/right 
control 




X 












X 


X 


33 


status/state 

(changes) 

detection/reporting 




X 


X 




X 








X 


34 


common notification 




X 


X 












X 


35 


messaging 






X 












X 


36 


presence 






X 












X 


37 


inter-destination 

media 

synclironization 






X 




X 








X 

























D.2 Mapping of elementary functions to functional entities 

Mapping of elementary functions in table D.2 show which elementary function (listed in clause 5.1.4) are applicable to 
functional entities (described in clause 5.1.3). 

Table D.2: Mapping of elementary functions to functional entities 





Elementary function 


UE 


SSF 


SDF 


Core IMS 


SCF 


UPSF 


MCF 


MDF 


1 


network attachment 


X 






X 










2 


registration 


X 






X 


X 








3 


resource management 








X 










4 


charging information 








X 


X 






X 


5 


service discovery 






X 












6 


service authorization 


X 




X 


X 










7 


service selection 


X 


X 














8 


service initiation 


X 








X 








9 


service control 


X 






X 


X 








10 


service information 
handling 


X 




X 












11 


service configuration 


X 






X 


X 








12 


session initiation 


X 






X 


X 








13 


session modification 


X 






X 


X 








14 


session termination 








X 


X 








15 


multicast based media 
delivery 
















X 


16 


unicast based media 
delivery 


X 














X 


17 


content download/ 
upload 


X 














X 


18 


control of multicast 
streaming 


X 












X 




19 


control of unicast 
streaming 


X 












X 




20 


control of download/ 
upload 


X 












X 




21 


content 
ingestion/receiving 


X 














X 


22 


content recording 


X 














X 


23 


content storage 


X 














X 


24 


content adaptation 
















X 


25 


content acquisition 


















26 


content validation 


















27 


content distribution 


















28 


content licencing 


















29 


key management 


















30 


content encryption 
















X 


31 


user profile/data mng. 


X 








X 


X 
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Elementary function 


UE 


SSF 


SDF 


Core IMS 


SCF 


UPSF 


MCF 


MDF 


32 


accounting/right control 








X 


X 


X 






33 


status/state (changes) 
detection/reporting 


X 








X 




X 


X 


34 


common notification 


X 








X 








35 


messaging 


X 








X 








36 


presence 


X 








X 








37 


inter-destination media 
synchronization 


X 








X 









D.3 Mapping of elementary functions to IPTV services 

Mapping of elementary functions in table D.3 show which elementary function (listed in clause 5.1.4) are applicable for 
described IPTV services (described in TS 181 016 [15]). 



£75/ 



160 



ETSI TS 182 027 V3.4.1 (2010-06) 



Table D.3: Mapping of elementary functions to IPTV services 





Elementary 
function 


BC 


CoD 


N-PVR 


C-PVR 


BCwTP 


UGC 


Push 
CoD 


Ad. 


CRS 


Notif. 


Msq 


Presen 
ce 


1 


network attachment 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


2 


registration 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


3 


resource 
management 


X 


X 


X 




X 


X 


X 


X 










4 


charging information 


X 


X 








X 


X 








X 




5 


service discovery 


X 




X 






X 














6 


service authorization 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


7 


service selection 


X 




X 


X 


X 


X 


X 












8 


service initiation 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


9 


service control 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


10 


service information 
handling 












X 






X 








11 


service configuration 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


12 


session initiation 


X 


X 


X 








X 












13 


session modification 


X 


X 


X 




X 


X 


X 












14 


session termination 


X 


X 


X 


X 


X 


X 


X 


X 


X 








15 


multicast based 
media delivery 


X 








X 






X 




X 






16 


unicast based media 
delivery 




X 


X 




X 


X 




X 




X 






17 


content download/ 
upload 












X 


X 


X 










18 


control of multicast 
streaming 


X 


X 


X 


X 


X 


X 


X 












19 


control of unicast 
streaming 


X 


X 


X 


X 


X 


X 


X 












20 


control of download/ 
upload 


X 


X 


X 


X 


X 


X 


X 












21 


content 
ingestion/receiving 


X 


X 


X 


X 


X 


X 


X 












22 


content recording 






X 


X 


X 
















23 


content storage 




X 


X 


X 




X 




X 










24 


content adaptation 


X 


X 












X 










25 


content acquisition 


X 


X 






X 


X 


X 


X 










26 


content validation 


X 


X 






X 


X 


X 












27 


content distribution 


X 


X 






X 


X 


X 


X 










28 


content licencing 


X 


X 






X 


X 


X 












29 


key management 


X 


X 






X 


X 


X 












30 


content encryption 


X 


X 






X 


X 


X 












31 


user profile/data 
mng. 
















X 


X 






X 


32 


accounting/right 
control 


X 


X 


X 


X 


X 


X 


X 






X 


X 




33 


status/state 

(changes) 

detection/reporting 




X 


X 




X 


X 


X 


X 


X 


X 




X 


34 


common notification 
















X 


X 


X 






35 


messaging 


















X 




X 




36 


presence 


















X 






X 


37 


inter-destination 

media 

synchronization 


X 


X 






X 


X 




X 
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Annex E (informative): 

Implementation Examples for Targeted Advertising 

Annex E describes implemtation examples for the following options: 

• Advertising performed exclusively by TISPAN IPTV entities. Also referred to an "Internal Advertising" 
option. 

• Advertising performed by an external system based on SCTE, [i.l2] to [i.l4]. Also referred to as an 
"SCTE-130 based External Advertising" option. 

• Advertising performed by an external system based on OMA. Also referred to as an "OMA MobAd based 
External Advertising" option. 

E.1 Internal Advertising Architecture Option 

This clause specifies the entities involved in the TISPAN-IPTV specific advertising architecture, the procecures and the 
interfaces involved between the TISPAN entities. 

E.1.2 Advertising architecture 

Refer to clause 5.1.1. 

E.1.3 Reference points 

Refer to clause 6. 

E.1 .4 Procedures for targeted ad insertion (TAI) 

In internal option, the Ad Server described in clause 8. 14 is instantiated to a logical SCF that is in charge of Ad service 
which is responsible for IPTV service status detection, ad content selection and subsequent ad service control. 

NOTE: In specialized implementation, the SCF in charge of Ad service (i.e. SCF2) can be co-located with the 
SCF in charge of BC, CoD or other IPTV services (i.e. SCFl). 

E.1 .4.1 Signalling flows for TAI at UE side 

When the ad insertion takes place at UE side, the UE is informed by ad insertion indication from SCF in charge of Ad 
service, and initiates individual session request for Ad content, which implies that multiple sessions may exist on the 
UE during the ad insertion time. 

Figure E. 1 depicts the typical steps when UE is informed of targeted ad insertion indication. 
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UE 



Core IMS 



SCFl 



1 Session initiation (clause 8) 



SCF2 



2 IPTV service 
status detection 



I 



3 Ad content selection 



MF 



4 Notification for ad insertion (8.11.1) 



5 Session initiation/modification for ad content (8.3.1/8.3.2/8.4.1/8.4.2) 



6 Ad insertion 



7 Session Release for ad content (8.3.3/8.4.3) 



Figure E.I : signalling flows for UE performing TAI 

1) Some IPTV session is established between UE and SCFl as procedures described in clause 8, e.g. BC session in 
clause 8.3, CoD session in clause 8.4 etc., and the related IPTV content is delivered to the UE. 

2) The SCF2 detects the ongoing IPTV service state (e.g. the current BC program ID, the commercial break of the 
program, the current CoD content id, the trick-play events, etc.) of specific user and decides to trigger ad 
insertion. Detection of the IPTV service status is done based on IPTV Service Action Data or using IPTV 
Presence information. 

3) SCF2 selects targeted ad content for the user, which can be inserted to the specific content. The user profile 
(e.g. shopping habits, user preference) is used to help locating of appropriate ad content targeted to specific user 
or user group. 

4) SCF2 sends UE the notification of ad insertion information, using procedures specified in clause 8.11.1. The ad 
insertion information includes the selected ad content identifier, insertion time (begin time and/or length), and 
other information needed for ad insertion. 

5) UE initiates the session initiation or modification procedure for ad content acquisition and the selected ad 
content is delivered to the UE. During this step the procedures described in clauses 8.3.1 and 8.3.2 for BC 
session or 8.4.1 and 8.4.2 for CoD session applies, with SCF2 responsible for the Ad service control and MF 
responsible for Ad content control and delivery. 

NOTE: The session modification is only possible when the same SCF handles CoD and Ad sessions. 

6) The UE performs the ad insertion, i.e. renders the ad content exclusively or in parallel with the ongoing IPTV 
content (e.g. in PiP). 

7) When the ad insertion times up, the session for ad content is released as procedures described in clauses 8.3.3 or 
8.4.3, and UE resumes the rendering of the IPTV content. 

E.1 .4.2 Signalling flows for TAI at MF side 

When the ad insertion takes place at MF, the MF is informed of the ad insertion information from the SCF2 and 
performs the ad insertion, i.e. delivery ad content to the UE during the ad insertion time of IPTV content play back. 

Figure E.2 depicts the typical steps when MF is informed of the ad insertion information. 
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Core IMS 



SCFl 



MF 



SCF2 



1 Session initiation (clause 8) 



2 IPTV service 
status detection 



I 



3 Ad content selection 



4 Ad insertion indicatio n 



5 Ad insertion 



6. Ad content provision 



Figure E.2 signalling flows for lUlF performing TAI 

1) Some IPTV session is established between UE and SCFl as procedures described in clause 8, e.g. BC session in 
clause 8.3, CoD session in clause 8.4 etc., and the related IPTV content is delivered to the UE. 

2) The SCF2 detects the ongoing IPTV service status (e.g. the current BC program ID, the commercial break of 
the program, the current CoD content id, the trick-play events) of specific user and decides to trigger ad 
insertion. Detection of the IPTV service status is done based on IPTV Service Action Data or using IPTV 
Presence information. 

3) SCF2 selects targeted ad content for the user, which can be inserted to the specific IPTV content. The user 
profile (e.g. shopping habits, user preference, etc.) is used to help locating of appropriate ad content targeted to 
specific user. 

4) SCF2 sends the ad insertion information to the MF which is responsible for IPTV content delivery and control. 
The information includes the selected ad content identifier(s) insertion time (begin time and/or length), and 
other information needed for ad insertion. Playlist information may be used as ad insertion information. 

NOTE: In the case of co-located entities, step 2 to 4 can be combined in step 1 . 

5) MF acquires the selected ad content and performs ad insertion, i.e. the selected ad content is delivered 
separately from the IPTV content or it is inserted as part of ongoing IPTV content. The MF may perform 
transcoding if the codec of ad content is not supported by the UE. The MF may perform session modification if 
needed (e.g; the ad content uses different network parameters, the stream is delivered separately, etc.). 

It is up to SCF preference/policy on how out-of-band insertion indicators work with the in-band insertion 
indicators, e.g. the in-band insertion indicator has precedence over the out-of-band indicator when both are 
present. 

6) The ad content is provided to the UE during the ad insertion time. 
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E.2 SCTE-130 Based External Advertising Architecture 
Option 

This clause specifies the entities defined by SCTE-130, complete architecture for advertising, the procedures and 
necessary interfaces between TISPAN and SCTE-130 entities. 

E.2.1 SCTE-130 Definitions 

SCTE-130 has defined the following advertising entities in [i.l2]: 

• Ad Decision Service (ADS): The Ad Decision Service determines how advertising content is combined with 
non-advertising (i.e. entertainment) content assets. The decisions made by an ADS may be straightforward 
(i.e. specific ad content placed at a specific time in a specific asset) or arbitrarily complex (based on subscriber 
data, advertising zone, etc.). 

• Ad Management Service (ADM): The Ad Management Service defines messages in support of ad insertion 
activities. The primary consumer of these messages is an ADS. The message interfaces exposed by an ADM 
allow for both preconfigured ad decisions as well as real-time fulfillment models. ADM detection of a 
placement opportunity is outside the scope of the specification. However, the ADM may be a service 
consumer of a POIS and/or a CIS in order to obtain such information. 

• Content Information Service (CIS): The Content Information Service manages metadata describing all the 
assets (both advertising assets and non-advertising assets) available to the other SCTE 130 logical services. 
The CIS provides query and notification interfaces to the other logical services. 

• Placement Opportunity Information Service (POIS): The Placement Opportunity Information Service 
(POIS) holds, maintains, or retains descriptions of placement opportunities. 

• Subscriber Information Service (SIS): The Subscriber Information Service manages the per-subscriber 
information relevant to ad placement decisions. The SIS provides mechanisms surrounding privacy issues. 

E.2.2 SCTE-1 30 based Advertising Architecture 

Figure E.3 shows the interfaces between the SCTE-130 advertising specific entities and the TISPAN IPTV architecture. 
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Figure E.3: Interaction between TISPAN IMS-based IPTV architecture and SCTE-130 advert entities 

The SCF entity can be interconnected with the Ad Decision service by the ADx reference point to request for placement 
decision. 

POIS is an external entity. SIS may be either covered by SCF, by SCF and UPSF, or by a complete external entity. 

The MF entity can be interconnected with the Ad Decision service by the ADy reference point to request placement 
decisions. 

The UE entity can be interconnected with the Ad Decision Service by the ADz reference point to request placement 
decisions. 

A deployment can have SCF,MF and/or the UE contact Ad Decision Service and perform ad insertion depending on the 
type of placement opportinuties that are detected by that particular entity. The option of where the ADM functions exist 
is a deployment choice that is not mandated by SCTE-130. 
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E.2.3 Reference points 

E. 2.3.1 IPTV Service Control Functions (SCF) - SCTE-1 30 External Ad 
system (ADx) 

This reference point is used to exchange advertising related messages between SCF and an SCTE-1 30 external 
Advertising sub-system. 

ADx reference point sends and receives messages from/to the ADS, POIS and SIS entities and the TISPAN IPTV SCF 
and conforms to appropriate SCTE130 part specification as indicated in [i.l2]. 

The use of ADx between SCF and ADS conforms to SCTE130-3 [i.l4]. It can be a subset of SCTE130-3 [i.l4] 
depending on the functionality supported in the SCF and ADS and that is declared during the discovery and registration 
phases. 

E. 2.3.2 IPTV Media Function (MF) - SCTE-1 30 External Ad system (ADy) 

This reference point is used to exchange advertising related messages between MF and an SCTE-1 30 external 
Advertising sub-system. 

ADy reference point should be used to send and receive messages from/to the ADS, POIS and SIS entites and the 
TISPAN IPTV MF and conforms to appropriate SCTE130 part specification as indicated in [i.l2]. 

The MF entity is interconnected with the Ad Decision service by the ADy reference point to made ad-selection and 
ad-placement requests for broadcast services. 

The use of ADy between MF and ADS conforms to SCTE130-3 [i.l4]. It can be a subset of SCTE130-3 [i. 14] 
depending on the functionality supported in the ADS and MF and that is declared during the discovery and registration 
phases. 

E. 2.3.3 IPTV User Equipment (UE) - SCTE-1 30 External Ad system (ADz) 

This reference point is used to exchange advertising related messages between UE and an SCTE-1 30 external 
Advertising sub-system. 

ADz reference point should be used to send and receive messages from/to the ADS, POIS entities and the TISPAN UE 
and conforms to appropriate SCTE130 part specification as indicated in [i.l2]. 

The UE entity is interconnected with the Ad Decision service by the ADz reference point to made ad-selection and 
ad-placement requests. 

The use of ADz between UE and ADS conforms to a relevant subset of SCTE130-3 [i.l4]. It can be a subset of 
SCTE130-3 [i.l4] depending on the functionality supported in the ADS and UE and that is declared during the 
discovery and registration phases. 

E.2.4 Procedures for Targeted Ad Insertion (TAI) 

Several deployment scenarios are supported by SCTE-1 30. The call flows below depicts specific example scenarios in 
which either the MF or the UE is involved in service state detection. Other deployment scenarios can have the SCF only 
being involved or the MF, UE and /or SCF being involved, where each entity handle different events. 

NOTE: Due to the stateful nature on the service channel established by the registration messages as described in 
SCTE 130-3 [i.l4], deployments should consider the scalability and load on the ADS while supporting 
this option. 
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E.2.4.1 Signalling flows for UE performing TAI 
E. 2.4.1 .1 UE detects service state 
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Figure E.4: Signalling flows for UE performing TAI(Case: UE detects service state) 

1) In the discovery step, the AD server becomes aware of the existence of the ADM. This can be through 
manually configuration, or by dynamically subscribing to an entity that can report to the AD server that a UE 
is online. 

2) The external AD server requests a list of offered placement services and capabilities, and receives these from 
the ADM logical entity in the UE. These actions of the external ad sub-system are not dependent on the 
existence of a session and can be triggered from a variety of sources, eg. network, application, external ad 

sub-system. 

3) Based on the current advertising campaign, the ad server (ADS) registers with a particular ADM, in this case 
the UE, with the placement services required. Pre-roll, post roll and interstitial placement opportunity 
existence is often pre-determined, and interactive applications such as CoD also offer the possibility of 
spontaneous placement opportunities provided by user events, eg. fast-forward, rewind, etc. 

4) An IPTV session is established between UE and SCF as described in clause 8, e.g. CoD session in 
clause 8.4.1.1, etc. and some IPTV content is delivered to the UE. 

5) The service state of on-going IPTV session is detected on the UE (e.g. the current CoD content id, the BC 
channel Id, the trick-play events, etc.). 
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6) The UE initiates a placement request to the Ad server and sends it the list of placement opportunities and 
other targeting information (service state of on-going session, user information, etc.) that allows the Ad Server 
to select the appropriate target ads. The Ad server responds with relevant placement/ad insertion information 
that can include the selected ad content identifier, insertion time (begin time and/or length), and other 
information needed for ad insertion. 

7) In order to retrieve the ads, the UE may perform session modification procedure in case the MF for the target 
ads is the same MF from which the streaming of the actual content occurs. Alternatively, the UE may also 
initiate a separate session to MF that includes the target ad content. During this step the procedures described 
in clause 8.4.2 for CoD session applies. 

NOTE: Other means such as off-line mechanisms can be also used to deliver the target ads to the UE, which are 
out of scope of the present document. 

8) The UE performs the ad insertion, i.e. renders the ad content embedded within the actual content or in parallel 
with the ongoing IPTV content (e.g. in PiP). 

9) When the ad insertion time is up, the session for ad content is released, if one has been created, and UE 
resumes the rendering of the IPTV content. 

10) A placement status message exchange takes place between the UE and the external ADS. The purpose of that 
exchange is to report placement decision fulfilment data and may include other events an ADM considers of 
interest to an ADS. Placement decision fulfilment data typically contains information regarding how the user 
viewed the ad content, along with any operations such as pause or fast-forward. 
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Figure E.5: Signalling flows for UE performing TAI 

Note that the discovery procedure is not shown here: 

1) The external AD server requests a list of offered placement services and capabilities, and receives these from 
the ADM logical entity in the MF. These actions of the external ad sub-system are not dependent on the 
existence of a session and can be triggered from a variety of sources, eg. network, application, external ad 

sub-system. 

2) Based on the current advertising campaign, the ad server (ADS) registers with a particular ADM, in this case 
the MF, with the placement services required. Pre-roll, post roll and interstitial placement opportunity 
existence is often pre-determined, and interactive applications such as CoD also offer the possibility of 
spontaneous placement opportunities provided by user events, eg. fast-forward, rewind, etc. 

3) An IPTV session is established between UE and SCF as described in clause 8, e.g. CoD session in 
clause 8.4.1.1 etc., and some IPTV content is delivered to the UE. 

4) The service state of on-going IPTV session is detected on the MF (e.g. the commercial break of the program, 
the current CoD content id, the trick-play events, etc.). 

5) The MF initiates a placement request/response exchange that allows the Ad Server to select the appropriate 
target ads which can be inserted in the currently streamed content. The ad insertion information can include the 
selected ad content identifier, insertion time (begin time and/or length), and other information needed for ad 
insertion. 
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6) The notification procedures specified in clause 8.11.1 are applied to deliver the ad insertion information to the 
UE. The ad insertion information can include the selected ad content identifier, insertion time (begin time 
and/or length), and other information needed for ad insertion. Other means for conveying the same information 
are also possible. 

7) In order to retrieve the ads, the UE may perform session modification procedure in case the MF for the target 
ads is the same MF from which the streaming of the actual content occurs. Alternatively, the UE may also 
initiate a separate session to MF that includes the target ad content. During this step the procedures described 
in clause 8.4.2 for CoD session applies. 

NOTE: Other means such as off-line mechanisms can be also used to deliver the target ads to the UE, which are 
out of scope of the present document. 

8) The UE performs the ad insertion, i.e. renders the ad content embedded within the actual content or in parallel 
with the ongoing IPTV content (e.g. in PiP). 

9) When the ad insertion time is up, the session for ad content is released, if one has been created, and UE 
resumes the rendering of the IPTV content. 

10) A placement status message exchange takes place between the MF and the external ADS. The purpose of that 
exchange is to report placement decision fulfilment data and may include other events an ADM considers of 
interest to an ADS. Placement decision fulfilment data typically contains information regarding how the user 
viewed the ad content, along with any operations such as pause or fast-forward. 
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E.2.4.2 Signalling flows for MF performing TAI 
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Figure E.6: Signalling flows for MF performing TAI 

Note that the discovery procedure is not shown here: 

1) The external AD server requests a Hst of offered placement services and capabilities, and receives these from 
the ADM logical entity in the MF. These actions of the ad sub-system are not dependent on the existence of a 
session and can be triggered from a variety of sources, eg. network, application, external ad sub-system. 

2) Based on the current advertising campaign, the ADS registers with a particular ADM, in this case the MF, with 
the placement services required. Pre-roll, post roll and interstitial placement opportunity existence is often 
pre-determined, and interactive applications such as CoD also offer the possibiUty of spontaneous placement 
opportunities provided by user events, eg. fast-forward, rewind, etc. 

3) An IPTV session is established between UE and SCF (CoD) as described in clause 8, e.g. CoD session in 
clause 8.4.1.1, etc., and some IPTV content is delivered to the UE. 

4) The service state of on-going IPTV session is detected on the MF (e.g. the commercial break of the program, 
the current CoD content id, the trick-play events, etc.). 
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5) The MF initiates a placement/request response exchange that allows the Ad Server to select the appropriate 
target ads which can be inserted in the currently streamed content. The ad insertion information can include the 
selected ad content identifier, insertion time (begin time and/or length), and other information needed for ad 
insertion.The means by which the MF acquires the ad content is outside scope. 

6) The MF performs the ad insertion, i.e. insert the ad content to the on-going IPTV content or replace the default 
ad content. The MF may perform transcoding or initiate session modification if the network parameters 

(e.g. codec or bandwidth) of ad content are not supported by the UE. Optionally, the ad content may be 
delivered to the UE via a new session. 

7) When the ad insertion time is up, the session for ad content is released, if one has been created, as procedures 
described in clause 8.4, and UE resumes the rendering of the IPTV content. 

8) A placement status message exchange takes place between the MF and the external ADS. The purpose of that 
exchange is to report placement decision fulfilment data and may include other events an ADM considers of 
interest to an ADS. Placement decision fulfilment data typically contains information regarding how the user 
viewed the ad content, along with any operations such as pause or fast-forward. 



E.3 OMA MobAd Based External Architecture Option 

This clause specifies the OMA MobAd (Mobile Advertising) entities, complete architecture for advertising, the 
procedures and necessary interfaces between TISPAN and OMA MobAd entities [i.l5] and [i.l6]. 

E.3.1 OIVIA MobAd Definitions 

Ad Server: Network resident functions specified by the MobAd Enabler [i.l6]. 

Ad Engine: Device resident functions specified by the MobAd Enabler [i.l6]. 

Ad App: An application running on the Device which interacts with the Ad Engine in order to present Ad(s) to the user. 

SP App: An Ad enabled network Application that is executing within the Service Provider environment (e.g. MMSC or 
SP-portal) and interacts with the MobAd Enabler for providing Ads as part of its service (e.g. requesting Ads, providing 
metrics data). SP App is not one of the MobAd Enabler Entities on the Network, but an external actor which interacts 
with them. 

Contextualisation: Tailoring and matching an advertising campaign to User's Context. In practical terms, this can 
include statically or dynamically associating a given User context (e.g.: "around Marble Arch in London, after 6pm, if 
using a streaming-capable Device"), to a varying degree of detail, with an advertising campaign. The above can imply 
using any data known and/or assumed about the User Context, e.g. location, device capabilities, etc. 

Personalisation: Tailoring and matching an advertising campaign to a set of User(s)' characteristics, such as 
demographics, tastes, preferences, etc. In practical terms, this can include statically or dynamically allocating a group of 
users which are to be participants in a given campaign, based on targeting criteria associated with a campaign. It can 
imply using static and dynamic data known and/or assumed about the User, which may be distributed in e.g.: User 
Profile, subscriber profiles, preferences and similar. This process can be self-improving throughout the campaign. 

NOTE: In this annex OMA's usage of the term "interface" is followed for consistency, this may differs from the 
use in other TISPAN's specification. 

Figure E.7 shows the OMA MobAd 1.0 architecture [i.l6]. 
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Figure E.7: OMA MobAd Architecture Diagram 

OMA MobAd 1.0 has defined the following advertising entities in [i.l6]: 

• Ad Server: The Ad Server is a MobAd enabler component resident in the network (outside the device) that 
performs actions grouped in the following high-level functions: 

Ad selection function: select the most appropriate Ad(s)/Ad Campaign(s) primarily using: 
Contextualisation and Personalisation information, Ad Metadata and applicable MobAd Rules. 

Ad delivery function: the delivery of Ad(s)/Ad Campaigns can be done via Pull, Push or Broadcast. 

Ad Metrics handling function: collect and process Ad Metrics data. 

User/service data management function: manage user's Personalisation and Contextualisation data, 
MobAd Rules, user groups. Ad Channels, etc. 

• Ad Engine: The Ad Engine (see clause E.4. 1 Definitions) is a MobAd Enabler component resident on the 
device that performs actions grouped in the following high-level functions: 

Ad acquisition and delivery function: the acquiring of Ad(s)/Ad Campaigns can be done via Pull, Push or 
Broadcast. 

Ad selection function: select Ads from the cache. 

Ad metrics handling function: augment Ad Metrics data received from Ad Apps and report it to the Ad 
Server. 

User/service/device data handling function: gather and process user's Personalisation and 
Contextualisation data, monitor and process device static and/or dynamic status (e.g. device resource 
threshold) and apply MobAd Rules. 

• SP App (SP Application): The SP App is an external entity that requests and receives Ad(s)/Ad Campaign(s) 
from Ad Server, and embeds them in content that is provided to the user. SP App records Ad Metrics data 
related to the Ad(s) and reports Ad Metrics data to the Ad Server. 
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• Ad App (Ad Application): The Ad App is an external entity running on the device that requests and receives 
Ad(s) from Ad Engine, and presents them to the user. Ad App also report Ad Metrics data to the Ad Engine. 

The interfaces defined in OMA Mob Ad 1.0 are: 

• MobAd-1 is an interface exposed by the Ad Engine to the Ad App. The Ad App uses this interface to request 
and obtain Ads and their associated Ads identifiers from the Ad Engine, as well as to report Ad Metrics data to 
the Ad Engine, accompanied by the associated Ads identifiers. 

• MobAd-2 is an interface exposed by the Ad Server to the SP App. The SP App uses this interface to request 
and obtain Ad(s), reference(s) to Ad(s), associated Ad(s) identifiers and possibly additional information (to be 
determined in the TS stage), as well as to report Ad Metrics data, accompanied by the associated Ad(s) 
identifier(s). 

• MobAd-3 is an interface exposed by the Ad Server to the Ad Engine. The Ad Engine uses this interface to 
request and obtain Ad(s), reference(s) to Ad(s), their associated Ad(s) identifier(s) and Ad Metadata from the 
Ad Server, as well as to report Ad Metrics data to the Ad Server, accompanied by the associated Ad(s) 
identifier(s). 

• Delv-1 is an optional interface exposed by the Ad Engine. The Ad Engine receives Ad(s) and/or Ad Metadata 
over this interface from the Ad Server via underlying push and/or broadcast delivery mechanisms. The Ad 
Server uses this interface to push either Ad(s) or notification that Ad(s) are available for retrieval. The Ad 
Server may also use this interface to provide service notification to the Ad Engine. 

E.3.2 OMA MobAd based Advertising Architecture 

Figure E.8 shows the interfaces between the OMA MobAd advertising specific entities and the TISPAN IPTV 
architecture. 
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Figure E.8: Interaction between TISPAN IMS-based IPTV architecture and OMA MobAd entities 

The SCF/MCF entities can be considered as SP App in MobAd and are interconnected with the Ad Server by the 
MobAd-2 interface to request for placement decision. 

The UE is interconnected with the Ad Server by the MobAd-3 interface to request Ad in case of Ad pulhng. 

E.3.3 Reference Points 

E.3.3.1 IPTV SCF/MCF - MobAd External Ad system (MobAd-2) 

This interface is used to exchange advertising related messages between SCF/MCF and a MobAd external Advertising 

sub-system. 

MobAd-2 interface should be used to exchange messages between the Ad Server and the TISPAN IPTV SCF/MCF. 
The use of MobAd-2 interface between SCF/MCF and Ad Server conforms to OMA MobAd AD [i.l6]. 



ETSI 



176 



ETSI TS 182 027 V3.4.1 (2010-06) 



E.3.3.2 IPTV UE - MobAd External Ad system (MobAd-3) 

This interface is used to exchange advertising related messages between UE and a MobAd external Advertising 

sub-system. 

MobAd-3 interface should be used to for the UE to request Ad from the Ad Server. 

The use of MobAd-3 interface between UE and Ad Server conforms to OMA MobAd AD [i.l6]. 

E.3.4 Procedures for Targeted Ad Insertion (TAI) 

In OMA MobAd option, the Ad Server described in clause 8. 14 is instantiated to the Ad Server (defined in OMA 
MobAd AD [i.l6]) that is in charge of Ad service which is responsible for ad content selection and subsequent ad 
service control. The SCF and MP are instantiated to the SP App (defined in OMA MobAd AD [i.l6]) which is a Service 
Provider Application system for ad request and ad response. 

E.3.4. 1 Signalling Flows for TAI at UE side 

When the ad insertion takes place at UE side, the UE is informed by ad insertion indication from SCF in charge of Ad 
service, and initiates individual session request for Ad content, which implies that multiple sessions may exist on the 
UE during the ad insertion time. 

Alternatively, the UE can request ad from Ad Server directly using the MobAd-3 interface, which is specified in OMA 
MobAd AD [i.l6]. UE can have the ad content stored locally for the ad insertion at the UE side. And also, the Ad 
Server can send appropriate ads to the MCE or MF beforehand to facilitate the ad request from UE. These can be done 
by offline means and out of scope of the present document. 

Figure E.9 depicts the typical steps when UE is informed of targeted ad insertion indication. 
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Figure E.9: signalling flows for UE performing TAI 

1) Some IPTV session is established between UE and SCF as procedures described in clause 8, e.g. BC session in 
clause 8.3, CoD session in clause 8.4 etc., and some IPTV content is delivered to the UE. 
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2) The SCF detects the ongoing IPTV service status (e.g. the current BC program ID, the commercial break of the 
program, the current CoD content id, the trick-play events, etc.) of specific user and decides to trigger ad 
insertion. Detection of the IPTV service status is done based on IPTV Service Action Data or using IPTV 
Presence information. 

3) The SCF sends a OMA MobAd Ad Request message to the target Ad Server for the user. The Ad Server 
acquires the contextualisation and personalisation data relavant to the user and selects the appropriate target ads. 
The ads on the Ad Server can be stored locally or come from external entities. The selected ads can be inserted 
in the currently streamed content. The Ad Server sends the OMA MobAd Ad Response message including the 
selected target ads information to the SCF. In step 3d, the SCF sends the target ad information and the ad 
insertion indication back to a selected MF. 

4) SCF sends UE the notification of ad insertion indication, using procedures specified in clause 8.11.1. The ad 
insertion indication includes the selected ad content identifier, the user id, insertion time (begin time and/or 
length), and other information needed for ad insertion. 

5) UE initiates the session initiation or modification procedure for ad content acquisition and the selected ad 
content is delivered to the UE. During this step the procedures described in clauses 8.3.1 and 8.3.2 for BC 
session or 8.4.1 and 8.4.2 for CoD session applies, with Ad Server responsible for the Ad service control and 
MF responsible for Ad content control and delivery. 

6) The UE performs the ad insertion, i.e. renders the ad content exclusively or in parallel with the ongoing IPTV 
content (e.g. in PiP). 

7) When the ad insertion times up, the session for ad content is released as procedures described in clauses 8.3.3 or 
8.4.3, and UE resumes the rendering of the IPTV content. 

E. 3.4.2 Signalling flows for TAI at MF side 

When the ad insertion takes place at MF, the MF is informed of the ad insertion indication from the SCF and performs 
the ad insertion, i.e. delivery ad content to the UE during the ad insertion time of IPTV content play back. 

Figure E.IO depicts the typical steps when MF is informed of the ad insertion indication. 



UE 



Core IMS 



SCF 



Ad Server 



1 Session initiation (clause 8) 



2 IPTV service 
status detection 



3 a OMA MobAd Ad Reqi est 



MF 



3c OMA MobAd Ad Response 



7. Ad conte it provision 



4 Ad insertion 



5 Ad content provision 



Figure E.10: signalling flows for MF performing TAI 

1) Some IPTV session is established between UE and SCFl as procedures described in clause 8, e.g. BC session in 
clause 8.3, CoD session in clause 8.4 etc., and some IPTV content is delivered to the UE. 
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2) The SCF detects the ongoing IPTV service status (e.g. the current BC program ID, the commercial break of the 
program, the current CoD content id, the trick-play events) of specific user and decides to trigger ad insertion. 
Detection of the IPTV service status is done based on IPTV Service Action Data or using IPTV Presence 
information. 

3) The SCF sends an OMA MobAd Ad rRequest message to the target Ad Server for the user. The Ad Server 
acquires the contextualisation and personalisation data relavant to the user and selects the appropriate target ads. 
The ads on the Ad Server can be stored locally or come from external entities. The selected ads can be inserted 
in the currently streamed content. The Ad Server sends the OMA MobAd Ad Response message including the 
selected target ad information to the SCF. In step 3d, the SCF sends the target ads informaion and the ad 
insertion indication back to a selected MF. 

4) MF acquires and stores the selected ad content, and performs ad insertion, i.e. the selected ad content is 
delivered separately from the IPTV content or it is inserted as part of ongoing IPTV content. 

5) The ad content is provided to the UE during the ad insertion time. 
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Annex F (informative): 

Mapping between TISPAN entities and external 

architectures 

Clause F.l describes a mapping of the functional entities defined by others Advertising standards with the TISPAN 
IPTV functional entities. 

F.1 IVIapping between TISPAN entities and SCTE-130 
entities 

This clause describes a mapping of the functional entities defined by SCTE with the TISPAN IPTV functional entities. 

Placement Opportunity Information Service (POIS) and Ad Decision Service (ADS) are considered out of scope of 
TISPAN architecture because placement opportunities providing and Advert placement decision are not defined as 
TISPAN entities tasks. Link between ADS and ADM is considered as a reference point in scope of TISPAN. 

Other modules can be mapped with current TISPAN entities as they cover TISPAN entities tasks. 

In table F.l, is presented entities defined in the SCTE-130 [i.l2] to [i.l4], their roles and concerned TISPAN entities. 
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Table F.1 



SCTE-1 30 entity 
name 


Role 


TISPAN Entity 
concerned 


TISPAN entity task covered 


POIS 


Provides placement opportunities 


Out of scope 
(external entity) 


- 


SIS 


IVIanage subscriber information 
relevant for Ad 


SCF/UPSF/External 
entity 


SCF task from clause 5.1 .5.2: 
Select appropriate ad content for 
specific user or user group, based 
on user profile (e.g. user 
preference, shopping habits, 
location information, etc.) and IPTV 
service status (e.g. current BC 
program ID, commercial break in BC 
service or pause during CoD 
content playback). 


CIS 


Manage assets metadata 


SCF 


SCF task from clause 5.1 .5.2: 
Select appropriate ad content for 

specific user or user group, based 
on user profile (e.g. user preference, 
shopping habits, location 
information, etc.) and IPTV service 
status (e.g. current BC program ID, 
commercial break in BC service or 
pause during CoD content 
playback). 


ADM 


Provides placement opportunities 

based on POIS and CIS 

information 

Defines messages for Ad insertion 

Activities 


SCF (for TAI) and MCF 
(for Broadcast) 


SCF tasks from clause 5.1 .5.2: 
Select appropriate ad content for 
specific user or user group, based 
on user profile (e.g. user preference, 
shopping habits, location 
information, etc.) and IPTV service 
status (e.g. current BC program 
ID, commercial break in BC 
service or pause during CoD 
content playback). 
Send ad insertion indication to MF 

MCF tasks from clause 5.1 .5.3: 
Handle ad insertion control of MDF, 
i.e. control the fetching of the ad 
content and synchronization 
between ad content and IPTV 
content, including accounting for 
delay or drift in broadcast TV 
schedules. 


ADS 


Decide ad placement relative to 
content based on ADM placement 
opportunities 


Out of scope 
(external entity) 





F.1 Mapping between TISPAN Entities and OIVIA IVIobAd 
Entities 

TISPAN entities can use the interfaces exposed by Ad Server and Ad Engine for advertising piuposes. 

Modules can be mapped with current TISPAN entities as they cover TISPAN entities tasks. 

Table F.2 shows the presented entities defined in the DMA MobAd, their roles and concerned TISPAN entities. 
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Table F.2 



OMA MobAd 
entity name 


Role 


TISPAN Entity 
concerned 


TISPAN entity task covered 


Ad Server 


Ad selection, Ad delivery, Ad 
Metrics data handling, data 
management 


Out of scope 


Use the interface exposed by Ad 
Server 


Ad Engine 


Ad selection, Ad acquisition and 
delivery. Ad IVIetrics data handling, 
data managment 


UE 


UE task from 8.14: 
When the ad insertion takes place at 
UE side, the UE is informed by ad 
insertion indication from SCF in 
charge of Ad service, and initiates 
individual session request for Ad 
content, which implies that multiple 
sessions exist on the UE during the 
ad insertion time. 


SP App 


Request and receive Ad, insert Ads 
to the content, report Ad Metrics 
data 


SCF/MF 


SCF task from clause 5.1 .5.2: 
Select appropriate ad content for 
specific user or user group, 
based on user profile (e.g. user 
preference, shopping habits, 
location information, etc.) and IPTV 
service status (e.g. current BC 
program ID, commercial break in BC 
service or pause during CoD 
content playback). 

MDF task from clause 5.1 .5.3: 
Recognize appropriate in-band 
/out-of-band Ad insertion 
indicators (eg-cue messages as 
defined in ITU-T Recommendation 
J.I 81 [1.18]), when present. These 
Ad insertion indicators define 
positions within the IPTV content 
where advertisement content can be 
inserted /replaced. This task may be 
done by coordination with an 
external advertising sub-system. 


Ad App 


Request and receive Ad, report Ad 
Metrics data 


UE 


UE task from 8.14: 
When the ad insertion takes place at 
UE side, the UE is informed by ad 
insertion indication from SCF in 
charge of Ad service, and initiates 
individual session request for Ad 
content, which implies that multiple 
sessions exist on the UE during the 
ad insertion time. 
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Annex G (informative): 
Ad placement options 

This annex presents examples for implemented of Ad placement by existing mechanism from other SDOs. 

G.1 IPTV Ad placement: SCTE-130 option 

In SCTE-130 [i.l4], four types of ad insertion opportunities exists: 

• Pre-roll (a placement opportunity preceding an entertainment asset). 

• Post-roll (a placement opportunity following the play out of an entertainment asset). 

• Interstitial (a placement opportunity occurring during the play out of an entertainment asset). 

• Pause (placement opportunity as a result of a subscriber pressing the pause button). 

They can be separated in two options: predetermined placement opportunities (Pre/Post roll and Interstitial) and 
unexpected placement opportunities (Pause). 

The predetermined option should be used for the following types of stored contents: BC, COD, N-PVR and UGC 
contents. 

The unexpected option could be used for all sorts of stored contents: BC with trick mode, COD, N-PVR, UGC, 
timeshift. 
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Annex H (informative): 

Interconnection IVIodels to support of IVIobility Capabilities 

TISPAN IMS based IPTV can recognize at least the following basic scenarios for roaming and interconnection to home 
network (not need support all of them): 

a) pure data access remotely to IPTV SP/content provider; 

b) IMS interconnect to home IPTV provider (described in clause H.l); 

c) visited - home network roaming between IPTV providers (served only from home network); 

d) visited - home network roaming between IPTV providers (served from home and/or visited network). 

Scenario A: IMS based IPTV user accessing via remote data access to home IPTV SP 

Because the UE accessing home IPTV SP from remote network without IMS, the user must use to connect UE to his 
home network some remote data IP connection (e.g. VPN or secure remote access). Over this connection can be 
transferred all media and signaling to the subscriber directly from his Home Network. Because such a connection 
should going over any IP network (also best effort) also without resource reservation mechanisms, no QoS can be really 
ensured. 

NOTE 1 : This scenario is out of scope of the current release. 

Scenario B: IMS based IPTV roaming with visiting IMS provider without IMS based IPTV solution 

This scenario is the simplest one with using core IMS. User will use IPTV services provided from IPTV functional 
elements from his Home Network. The IMS elements of visited network must do just IMS roaming via network 
attachment and registration in visited network and forward all other request to home network and its IMS IPTV SP 
(e.g. registration, service discovery/selection, service initiation/modification/termination). Service selection information 
and media are delivered from Home network over interconnection. 

The quality of the IPTV service for the end customer should be same as in home network (when interconnection and 
visited network assure enough resources and QoS), but no reuse of local media delivery resources for the provider is 
possible (because in visited network have no IMS based IPTV platform). 

NOTE 2: This scenario is described in clause H.l. 

Scenario C: IMS based IPTV roaming with visiting IPTV Service Provider with TISPAN IMS-IPTV solution 
(only home served) 

Additionally to the previous scenario the following one expects the IMS based IPTV platform is available in Visited 
Network, however all content and services are delivered only from Home Network. This solution expect that delivery of 
the content, metadata and service discovery, selection and service initiation, modification and termination will be done 
from home network. Also it could be required from Home Network IMS based IPTV solution to provide transcoding 
and content adaptation to adapt media to parameters required for entering the Visited Network (or this could be done in 
edge of visited network). 

Scenario D: IMS based IPTV roaming with visiting IPTV Service Provider with IMS-IPTV solution (home 
and/or partially visited IPTV platform served) 

If there is an IPTV solution in Visited Network, possibly having similar content for CoD, BC, PVR service, it is useful 
and more efficient to use this local resources in visited network as deliver all content over interconnection. The content 
which is available in Visited Network is not needed to be transferred over an interconnection network and allocate 
interconnection bandwidth/resources. For this purpose both providers should agree on the same identification of 
content, sharing service discovery and selection information, content security, billing clearing, and for sure about all 
parameters required for roaming agreements (e.g. QoS, Service Level Agreement). Other IPTV services or content not 
available in offer of visited IMS IPTV SP are provided as in previous scenario by home network and by user home 
IPTV service provider. 
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H.1 Interconnection model using IIVIS roaming to home 
IMS IPTV 

Figure H. 1 illustrates the model of interconnection with the Visited Network within Core IMS involved. UE can request 
IPTV services in the Home Network by connecting to the Visited Network. Core IMS in the Visited Network can 
request resources from the RACS in the Visited Network through the interface Gq'. Core IMS in the Home Network can 
request resources from the RACS in the Home Network through the interface Gq'. UE can attach to the Visited Network 
through the interface el so that the NASS in the Visited Network can assign IP address for the UE and discovery the 
address of P-CSCF in the Visited Network. Core IMS in the Visited Network can transfer the IPTV service request 
from the UE through the interface Ic to the Core IMS in the Home Network through the connection of their own 
IBCF(Intermediate Breakout Control Function). UE can connect the SSF to select IPTV services through the interface 
Xa which is already defined. UE can connect to the IPTV SCF to configure parameters through the interface Ut which 
is already defined. Core IMS in both network connect to their own UPSF to get user profiles through their own interface 
Cx. 



Visited Network 



Home Networl< 



IPTV Service 

Control 

Functions 



IPTV Media 
Control 
Functions 



IPTV Media Functions 




IPTV Media 
Delivery 
Functions 



Figure H.I 



H.2 Signalling flows 



The clauses below explain the signalling flows of UE start-up procedures and CoD procedures when the UE is located 
in the Visited Network. In Broadcast procedures, N-PVR and other services, they are similar as CoD procedures. 

NOTE: Following procedure are indicative to show one possible way how should IMS roaming be handle 
between home and visited network. 
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H.2.1 UE Start-up procedures 



UE 



1 . N 3twork Attachmdnt 



Visited Networl< 



NASS 



Core IMS 



2.1 



\AS Registration 



4. Return Para. 



Home Networl< 



Core IIVIS 



3. IMS Registration 



SDF 



SSF 



5 Attachment and selection of IPTV Services 



Figure H.2 

1) Network Attachment 

In this step the UE attaches to the network. The procedures for network attachment are defined in 

ES 282 004 [3]. This step includes IP configuration, P-CSCF address discovery of Visited Network, etc. 

2) IMS Registration in Visited Network 

In this step, the UE performs regular IMS Registration as defined in TS 182 006 [2]. 

3) P-CSCF within Core IMS in Visited Network submits the registration request to the I-CSCF within the Core 
IMS in the Home Network. 

In this step, the UE performs regular IMS Registration as defined in TS 123 002 [i.8]. 

4) Core IMS in the Visited Network return parameters (e.g. P-CSCF address of Home Network) to the UE. 

5) The step is the same as step 3 to 4 in figure 9 of clause 8.2. 
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H.2.2 CoD procedures 
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Res ponse 



12. Content Control and/or Delivery 



Figure H.3 

1) The UE initiates a dialogue to the CoD service and submit the request to the Core IMS in the Visited Network, 
similar to steps 3 to 5 in clause 8.4.1.1.1. 

2) Core IMS in the Visited Network forwards the request to the Core IMS in the Home Network. 

3) The session initiation request is routed by the Core IMS in the Home Network up to the SCF. 

4) The SCF performs service authorization as described in clause 5.1. If the UE is allowed to access the content, 
the SCF forwards the session initiation request to the selected MF. 

5) Signalling procedures for establishment of a content control channel and optionally content delivery channels 
take place between the UE and the MF (see similar clause 8.4.1.2.1). 

6 to 8) The steps are the same as step 7 to 10 not including step 8 of clause 8.4.1.1.1. 

9) The Core IMS in the Home Network forwards this confirmation to the Core IMS in the Visited Network. 

10) The P-CSCF within the Core IMS in the Visited Network interacts with the RACS in the Visited Network to 
commit all resources previously reserved. This includes opening pinholes for exchanging content control 
messages and/or content delivery. 

11) The P-CSCF in the Visited Network forwards the dialogue confirmation to the UE. 
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After this point, UE may use the content control channel to request content to be streamed and the actual content will 
then be delivered to the UE. The content control channel will also be used to carry UE requests for controlling the 
streams, e.g. "pause", "fast forward", etc. 

NOTE: Resources reserve/commit between Core IMS and RACS in the home network is optional when selected 
MP in the visited network servers the UE. 
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Annex I (informative): 
IPTV Identifiers 



This annex provides an overview of generic IPTV identifiers used in the present document. 



1.1 



IPTV content identifiers 



Table I.l provides an overview over IPTV content identifiers. 



Table 1.1 : IPTV content identifiers 



IPTV Service 


IPTV content 
identifier 


Clause(s) 


Identifies ... 


BC 


BCServiceld 


7.4.1 


...a BC channel 


BC 


Programmeld 


7.4.1 


... a BC programme 


CoD 


CoDId 


7.4.1 


... CoD 


PVR 


PVRContentId 


7.4.1 


...PVR content 


UGC 


UGC content id 


8.9.2 


...UGC 


Ad 


ad content id 


8.14.1 


...an advertisement clip 


PCh 


PCIild 


8.10 


...a personalized channel 



NOTE: In case of BC, the IPTV content identifier contains the BCServiceld, the Programmeld or both. 
Table 1.2: Use of IPTV content identifiers by other IPTV services 



Other IPTV 
service/feature 


Clause(s) 


IPTV content identifier is used to identify content that is ... 


BC 


N/A 


(only BC content) 


CoD 


N/A 


(only CoD content) 


PVR 


7.1 


... used by the UE to activate a PVR session related to the PVR content 


Time shift 


N/A 


... time-shifted 


Preview 


8.7 


... previewed 


Parental controlled 


- 


... parentally controlled 


UGC 


N/A 


(only UGC content) 


PCh 


8.10 


... concatenated into a personalised channel 


CR 


8.13 


... recommended by the CR service 


Ad 


8.14.1.1 


... subjected to ad insertion 


Sync 


8.15 


... synchronised 


Trick-play 


8.16 
8.20 


... controlled through network-controlled trick play 


Push CoD 


N/A 


(only CoD content) 


Content 
upload/download 


8.18 
8.19 


... up/downloaded 


SSC 


8.21 


... controlled together with other users 


PSC 


8.22 


... used to build a personalised service composition 


Content marker 


7.5.2.5 
8.23 


... marked 


Remote UE 


8.25 


... remotely inflated and controlled 


Presence 


9.1 


... being watched, as published to other users and/or IPTV services 



1.2 IPTV service type identifier 

Table 1.3 provides an overview over IPTV service types that are identified by an IPTV service type identifier. 
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Table 1.3: IPTV service type identifiers 



IPTV Service Type 



Broadcast (BC) 



Broadcast with trick play 



Content on Demand (CoD) 



Personal Video Recorder (PVR) 



Network Personal Video Recorder (N-PVR) 



Consumer Personal Video Recorder (C-PVR) 
Time shift 



Preview 



Parental controlled (PC) 



User Generated Content (UGC) 



Personalised Channel (PCh) 



Content Recommendation (CR) 



Targeted Advertisement Insertion (TAI) 



Push Content on Demand 



Content upload/download 



Shared Service Control (SSC) 



Personalised Service Composition (PSC) 
Content marker (CIVI) 



Remote UE 
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